BASES DE DATOS

MIS 308

4.

DISEO DE BASES DE DATOS RELACIONALES

Introduccin 4.1 Definicin del problema 4.2 Solucin de problemas 4.3 Normalizacin: 1NF, 2NF, 3FN 4.4 Criterios para normalizar

Introduccin
Como ya hemos visto en los Subtemas Nos. 2.4 y 3.4 los Modelos Relacionales son de los utilizados muy ampliamente y recordando que el modelo es la base (core) para los DBMS es importante refrendar los conceptos bsicos y de donde vienen. Muchas disciplinas (y sus metodologas de diseo asociadas) tienen algn tipo de base terica. Los ingenieros industriales disean estructuras utilizando teoras de la fsica. Los compositores crean sinfonas utilizando conceptos de teora de la msica. La industria del automvil utiliza teoras de la aerodinmica para disear automviles con menor consumo. La industria aeronutica utiliza las mismas teoras para disear alas de aviones que reduzcan la resistencia al viento. Estos ejemplos demuestran que la teora es muy importante. La ventaja principal de la teora es que hace que las cosas sean predecibles: nos permite predecir qu ocurrir si realizamos una determinada accin. Por ejemplo, sabemos que si soltamos una piedra, caer al suelo. Si somos rpidos, podemos apartar nuestros pies del camino de la teora de la gravedad de Newton. Lo importante es que siempre funciona. Si ponemos una piedra plana encima de otra piedra plana, podemos predecir que se quedarn tal y como las hemos puesto. Esta teora permite disear pirmides, catedrales y casas de ladrillos. Consideremos ahora el ejemplo de una base de datos relacional. Sabemos que si un par de tablas estn relacionadas, podemos extraer datos de las dos a la vez, simplemente por el modo en que funciona la teora de las }bases de datos relacionales. Los datos que se saquen de las dos tablas se basarn en los valores coincidentes del campo que ambas tienen en comn. Una vez ms, nuestras acciones tienen un resultado predecible. El modelo relacional se basa en dos ramas de las matemticas: la teora de conjuntos y la lgica de predicados de primer orden. El hecho de que el modelo relacional est basado en la teora de las matemticas es lo que lo hace tan seguro y robusto. Al mismo tiempo, estas ramas de las
1

BASES DE DATOS

MIS 308

matemticas proporcionan los elementos bsicos necesarios para crear una base de datos relacional con una buena estructura, y proporcionan las lneas que se utilizan para formular buenas metodologas de diseo. Hay quien ofrece una cierta resistencia a estudiar complicados conceptos matemticos para tan slo llevar a cabo una tarea bastante concreta. Es habitual escuchar quejas sobre que las teoras matemticas en las que se basa el modelo relacional y sus metodologas de diseo, no tienen relevancia en el mundo real o que no son prcticas. No es cierto: las matemticas son bsicas en el modelo relacional. Pero, por fortuna, no hay que aprender teora de conjuntos o lgica de predicados de primer orden para utilizar el modelo relacional. Sera como decir que hay que saber todos los detalles de la aerodinmica para poder conducir un automvil. Las teoras de la aerodinmica ayudan a entender cmo un automvil puede ahorrar combustible, pero desde luego no son necesarias para manejarlo. La teora matemtica proporciona la base para el modelo relacional y, por lo tanto, hace que el modelo sea predecible, fiable y seguro. La teora describe los elementos bsicos que se utilizan para crear una base de datos relacional y proporciona las lneas a seguir para construirla. El organizar estos elementos para conseguir el resultado deseado es lo que se denomina diseo. En 1970, el modo en que se vean las bases de datos cambi por completo cuando E. F. Codd introdujo el modelo relacional. En aquellos momentos, el enfoque existente para la estructura de las bases de datos utilizaba punteros fsicos (direcciones de disco) para relacionar registros de distintos ficheros. Si, por ejemplo, se quera relacionar un registro con un registro , se deba aadir al registro un campo conteniendo la direccin en disco del registro . Este campo aadido, un puntero fsico, siempre sealara desde el registro al registro . Codd demostr que estas bases de datos limitaban en gran medida los tipos de operaciones que los usuarios podan realizar sobre los datos. Adems, estas bases de datos eran muy vulnerables a cambios en el entorno fsico. Si se aadan los controladores de un nuevo disco al sistema y los datos se movan de una localizacin fsica a otra, se requera una conversin de los ficheros de datos. Estos sistemas se basaban en el modelo de red y el modelo jerrquico, los dos modelos lgicos que constituyeron la primera generacin de los DBMS. El modelo relacional representa la segunda generacin de los DBMS. En l, todos los datos estn estructurados a nivel lgico como tablas formadas por filas y columnas, aunque a nivel fsico pueden tener una estructura completamente distinta. Un punto fuerte del modelo relacional es la sencillez de su estructura lgica. Pero detrs de esa simple estructura hay un fundamento terico importante del que carecen los DBMS de la primera generacin, lo que constituye otro punto a su favor.
2

BASES DE DATOS

MIS 308

Dada la popularidad del modelo relacional, muchos sistemas de la primera generacin se han modificado para proporcionar una interfaz de usuario relacional, con independencia del modelo lgico que soportan (de red o jerrquico). Por ejemplo, el sistema de red IDMS ha evolucionado a IDMS/R e IDMS/SQL, ofreciendo una visin relacional de los datos. En los ltimos aos, se han propuesto algunas extensiones al modelo relacional para capturar mejor el significado de los datos, para disponer de los conceptos de la orientacin a objetos y para disponer de capacidad deductiva. El modelo relacional, como todo modelo de datos, tiene que ver con tres aspectos de los datos:
o o o

Estructura de datos. Integridad de datos. Manejo de datos.

4.1 Definicin del problema

La definicin del problema es el proceso por el que se determina la organizacin de una base de datos, incluidos su estructura, contenido y las aplicaciones que se han de desarrollar. Durante mucho tiempo, el diseo de bases de datos fue considerado una tarea para expertos: ms un arte que una ciencia. Sin embargo, se ha progresado mucho en el diseo de bases de datos y ste se considera ahora una disciplina estable, con mtodos y tcnicas propios. Debido a la creciente aceptacin de las bases de datos por parte de la industria y el gobierno en el plano comercial, y a una variedad de aplicaciones cientficas y tcnicas, el diseo de bases de datos desempea un papel central en el empleo de los recursos de informacin en la mayora de las organizaciones. El diseo de bases de datos ha pasado a constituir parte de la formacin general de los informticos, en el mismo nivel que la capacidad de construir algoritmos usando un lenguaje de programacin convencional Para definir correctamente al Problema lo primero es realizar diseo conceptual, que parte de las especificaciones de los requisitos del usuario y su resultado es el esquema conceptual de la base de datos que corresponder a un Modelo Entidad Relacin (E / R). Un esquema conceptual es una descripcin de alto nivel de la estructura de la base de datos, independientemente del DBMS que se vaya a utilizar para manipularla. Un modelo conceptual es un lenguaje que se utiliza para describir esquemas conceptuales. El objetivo del diseo conceptual es describir el contenido de los Datos de la base de datos (DB) y no las
3

BASES DE DATOS

MIS 308

estructuras de almacenamiento que se necesitarn para manejar esta informacin. El modelo relacional representa un sistema de bases de datos en un nivel de abstraccin un tanto alejado de los detalles de la mquina subyacente, de la misma manera como, por ejemplo, un lenguaje del tipo de PL/1 representa un sistema de programacin con un nivel de abstraccin un tanto alejado de los detalles de la mquina subyacente. De hecho, el modelo relacional puede considerarse como un lenguaje de programacin mas bien abstracto, orientado de manera especfica hacia las aplicaciones de bases de datos [Date, 1993] En trminos tradicionales una relacin se asemeja a un archivo, una tupla a un registro, y un atributo a un campo. Pero estas correspondencias son aproximadas, en el mejor de los casos. Una relacin no debe considerase como ``solo un archivo'', sino mas bien como un archivo disciplinado, siendo el resultado de esta disciplina una simplificacin considerable de las estructuras de datos con las cuales debe interactuar el usuario, lo cual a su vez simplifica los operadores requeridos para manejar esas estructuras. Caractersticas principales de los ``archivos'' relacionales:

Cada ``archivo'' contiene solo un tipo de registros Los campos no tienen un orden especfico, de izquierda a derecha Los registros no tienen un orden especfico, de arriba hacia abajo Cada campo tiene un solo valor Los registros poseen un campo identificador nico (o combinacin de campos) llamado clave primaria

As, todos los datos en una base de datos relacional se representan de una y solo una manera, a saber, por su valor explcito (esta se denomina en ocasiones ``principio bsico del modelo relacional''). En particular, las conexiones lgicas dentro de una relacin y entre las relaciones se representan mediante esos valores; no existen ``ligas'' o apuntadores visibles para el usuario, ni ordenamientos visibles para el usuario, ni grupos repetitivos visibles para el usuario, etc. Actualmente algunos de los manejadores de bases de datos, utilizan un sistema de bsqueda con algoritmos de rboles b. Pero las bsquedas que se pueden realizar con estos algoritmos son slo para memoria principal. Los algoritmos implementados para realizar bsquedas con listas salteadas o por bloques (skip lists) son eficientes para realizar bsquedas en memoria secundaria. Como tienen varios niveles en cada
4

BASES DE DATOS

MIS 308

nodo de la lista, nos permite dar saltos mas largos al realizar las bsquedas, esto provoca que las sean mas rpidas.

El primer paso para la definicin del Problema l diseo de una base de datos es la produccin del esquema conceptual. Normalmente, se construyen varios esquemas conceptuales, cada uno para representar las distintas visiones que los usuarios tienen de la informacin. Cada una de estas visiones suelen corresponder a las diferentes reas funcionales de la empresa como, por ejemplo, produccin, ventas, recursos humanos, etc. A los esquemas conceptuales correspondientes a cada vista de usuario se les denomina esquemas conceptuales locales. Cada uno de estos esquemas se compone de entidades, relaciones, atributos, dominios de atributos e identificadores. El esquema conceptual tambin tendr una documentacin, que se ir produciendo durante su desarrollo. Las tareas a realizar en el diseo conceptual son las siguientes: 1. 2. 3. 4. 5. 6. 7. 8. Identificar las entidades. Identificar las relaciones. Identificar los atributos y asociarlos a entidades y relaciones. Determinar los dominios de los atributos. Determinar los identificadores. Determinar las jerarquas de generalizacin (si las hay). Dibujar el diagrama entidad-relacin. Revisar el esquema conceptual local con el usuario

El modelo Entidad-Relacin (E/R) se basa en una representacin del mundo real en que los datos se describen como entidades, relaciones y atributos. El principal concepto del modelo ER es la entidad, que es una "cosa" en el mundo real con existencia independiente. Una entidad puede ser un objeto fsico (una persona, un auto, una casa o un empleado) o un objeto conceptual (una compaa, un puesto de trabajo o un curso universitario). En nuestro ejemplo de la seccin anterior podemos definir dos entidades alumnos y cursos. Cada entidad tiene propiedades especficas, llamadas atributos, que la describen. Por ejemplo, una sala de clases tiene un nombre, una ubicacin, un cupo mximo, etc. En nuestro ejemplo, la entidad "alumno"
5

BASES DE DATOS

MIS 308

posee los atributos nombre y matrcula. Una entidad particular tiene un valor para cada uno de los atributos. Cada uno de los atributos de una entidad posee un dominio, el que corresponde al tipo del atributo. Por ejemplo, "matrcula" tiene como dominio al conjunto de los enteros positivos y "nombre" tiene como dominio al conjunto de caracteres. Para todo conjunto de valores de una entidad, debe existir un atributo o combinacin de atributos, que identifique a cada entidad en forma nica. Este atributo o combinacin de atributos se denomina llave (primaria). Por ejemplo, el nmero de matricula es una buena llave para la entidad alumno, no as el nombre, porque pueden existir dos personas con el mismo nombre. Una relacin se puede definir como una asociacin entre entidades. Por ejemplo, la entidad "libro" puede estar relacionada con la entidad "persona" por medio de la relacin "est pedido". La entidad "alumno" puede estar relacionada con la entidad "curso" por la relacin "est inscrito". Una relacin tambin puede tener atributos. Por ejemplo, la relacin "est inscrito" puede tener los atributos "semestre" y "nota de aprobacin".

DIAGRAMA FASES DISENO DB

NOTA PARA VER BIEN EL DIAGRAMA PONER ZOOM A 150

Ejemplo:
6

BASES DE DATOS

MIS 308

Suponga que estamos modelando los datos de una COMPAIA. La base de datos COMPAIA debe mantener los Datos sobre los empleados de la compaa, los departamentos y los proyectos. La descripcin del minimundo (la parte de la compaa a ser representada en la base de datos) es la siguiente: 1. La compaa est organizada en departamentos. Cada departamento tiene un nombre nico. Un nmero nico, y un empleado particular quien lo administra. Se quiere saber la fecha en que el empleado administrador empez a hacerse cargo del departamento. Un departamento puede tener varios locales. 2. Cada departamento controla un cierto nmero de proyectos. Cada proyecto tiene un nombre y nmero nicos, y un local. 3. Para cada empleado se desea tener su nombre, rut, direccin, salario, sexo y ao de nacimiento. Un empleado es asignado a un departamento, pero puede trabajar en varios proyectos, los que no son necesariamente controlados por el mismo departamento. Se quiere saber el nmero de horas semanales que un empleado trabaja en cada proyecto. Se quiere adems saber cul es el supervisor directo de cada empleado. 4. Se desea conocer las personas dependientes de cada empleado para propsitos de seguros. De cada dependiente se desea conocer el nombre, sexo, fecha de nacimiento y relacin con el empleado. La siguiente figura muestra el esquema de esta base de datos, a travs de una notacin grfica llamada diagrama ER.

BASES DE DATOS

MIS 308

En este diagrama los rectngulos representan conjuntos de entidades, las elipses representan atributos y los rombos representan conjuntos de relaciones. Usando esta notacin, podemos ahora hacer el diagrama E-R del ejemplo anterior de los alumnos y los cursos matriculados.

Tipos de relaciones Un tipo de relacin R entre n tipos de entidades E1, ..., En define un conjunto de asociaciones entre estos tipos.
8

BASES DE DATOS

MIS 308

Puede ser visto como un conjunto de instancias de la relacin ri, donde cada ri asocia n entidades (e1, ..., en), y cada entidad ej en ri es un miembro del tipo de entidad Ej (1 <= j <= n). Un tipo de relacin es un subconjunto del producto cartesiano E1 x E2 x ... x.En. Ejemplo. Algunas instancias de la relacin TRABAJA_PARA del ejemplo anterior, podran ser las siguientes.

Un tipo de relacin podra tambin interpretarse como un conjunto de pares ordenados, en este caso: (e1, d1), (e2, d2), (e3, d1), (e4, d2), (e5, d3), (e6, d1), (e7, d3). Segn el nmero de entidades relacionadas (o razn de cardinalidad), se pueden definir tres tipos de relaciones: 1. Relaciones Uno a Uno (1:1). Una entidad A est asociada a lo ms con una entidad B, y una entidad B a lo ms con una entidad A. Ejemplo: "Ser jefe de" es una relacin 1:1 entre las entidades empleado y departamento. 2. Relaciones Uno a Muchos (1:n). Una entidad A est asociada con una o varias entidades B. Una entidad B, sin embargo, puede estar a lo ms asociada con una entidad A. Ejemplo: "Ser profesor" es una relacin 1:n entre profesor y curso, suponiendo que un curso slo lo dicta un profesor.
9

BASES DE DATOS

MIS 308

3. Relaciones Muchos a Muchos (n:m). Una entidad A est asociada con una o varias entidades B, y una entidad B est asociada con una o varias entidades A. Ejemplo: "Estar inscrito" es una relacin n:m entre las entidades alumno y curso. El siguiente es un ejemplo de la relacin ADMINISTRA, con participacin parcial de EMPLEADOS, y participacin total de DEPARTAMENTOS.

La siguiente figura muestra un ejemplo de la relacin M:N TRABAJA_PARA.

Tipos de atributos

10

BASES DE DATOS

MIS 308

Los atributos compuestos se pueden dividir en sub-partes ms pequeas, que representan atributos ms bsicos con significados propios. Por ejemplo, una "direccin" puede sub-dividirse en: dir-calle, comuna, ciudad, regin. Ejemplo:

Los atributos no sub-dividibles se llaman atmicos o simples. Si no hay necesidad de referirse a los elementos individuales de una direccin, entonces la direccin completa puede considerarse un atributo simple. Atributos de valor simple son los que tienen un slo valor para una entidad particular. Por ejemplo: edad. Atributos multivalorados pueden tener un conjunto de valores para una misma entidad. Por ejemplo: "ttulos profesionales" (una persona puede no tener ninguno, uno, dos o ms). En algunos casos una entidad particular puede no tener valores aplicables para un atributo. Ejemplo: "depto". Para estas situaciones tenemos un valor especial llamado nulo. Tambin, si no se conoce el valor. Un tipo de entidad define un conjunto de entidades con los mismos atributos. Ejemplo: Nombre del tipo de entidad: EMPLEADO Atributos: Nombre, Edad, Sueldo Conjunto de entidades: (Juan Prez, 55, 800.000), (Federico Pardo, 40, 550.000), (Rodrigo Pozo, 25, 400.000). En los diagramas E-R, un tipo de entidad se representa como una caja rectangular, los nombres de los atributos como elipses y las relaciones
11

BASES DE DATOS

MIS 308

como rombos. Los atributos multivalorados se representan con elipses dobles. Un tipo de atributo usualmente tiene un atributo cuyos valores son distintos para cada entidad individual (atributo clave o llave) y sus valores se usan para identificar cada entidad unvocamente. Para una entidad tipo PERSONA, un atributo clave tpico es el RUT. Algunas veces, varios atributos juntos forman una clave (la combinacin debe ser distinta). Estos atributos clave aparecen subrayados en los diagramas. Cada atributo simple tiene un conjunto de valores o dominio asociado, que especifica el conjunto de valores que puede asignarse a cada entidad individual. Por ejemplo, si las edades de los empleados pueden variar entre 16 y 70, entonces el dominio de Edad es {x N / 16 <= x <= 70}. Los dominios no se muestran en los diagramas. Un atributo A del tipo de entidad E cuyo dominio es V, puede definirse como una funcin de E al conjunto potencia V (conjunto de todos los subconjuntos de V): A: E <e> P(V) El valor del atributo A para la entidad e es A(e). Un valor nulo se representa por el conjunto vaco. Para un atributo compuesto A, el dominio V es el producto cartesiano de P(V1), ..., P(Vn) donde V1, ..., Vn son los dominios de los atributos simples que forman A: V = P(V1) x P(V2) x ... x P(Vn). Notemos que atributos compuestos y multivalorados pueden ser anidados de cualquier manera. Podemos representar anidamiento agrupando componentes de un atributo compuesto entre parntesis ( ), separando componentes con comas, y mostrando atributos multivalor a dos entre llaves {}. Ejemplo: Si una persona puede tener ms de una direccin, y en cada una de ellas hay mltiples telfonos, podemos especificar un atributo DirTel para una PERSONA as: { DirTel ( { Telfono ( CdigoArea, NumTel ) }, Direccin ( DirCalle ( Calle, Nmero, NumDepto ), Comuna, Ciudad, Regin ) ) } La persona Juan Prez puede tener una instancia de este atributo as: { DirTel ( { Telfono ( 2, 442-2855 ) }, Direccin ( DirCalle ( Blanco, 2120, nulo ), Santiago, Santiago, RM ) ), DirTel ( { Telfono ( 2, 241-3416 ) },
12

BASES DE DATOS

MIS 308

Direccin ( DirCalle ( Manuel Montt, 74, 201 ), Providencia, Santiago, RM ))} Este modelo considera la Base de Datos (BD) como una coleccin de relaciones. De manera simple, una relacin representa una tabla, en que cada fila representa una coleccin de valores que describen una entidad del mundo real. Cada fila se denomina tupla. Dominios, tuplas, atributos, relaciones Un dominio D es un conjunto de valores atmicos. Atmico quiere decir que cada valor en el dominio es indivisible. Es til dar nombres a los dominios. Ejemplo:Nmeros-telefnicos-locales: el conjunto de nmero de telfono de 7 dgitos. RUTs: nmeros de 8 dgitos ms un carcter que puede ser del 0 al 9 o K Nombres: el conjunto de nombres de personas Notas: valores entre 1.0 y 7.0 Tambin se puede especificar un tipo de datos o formato para cada dominio. Un esquema de relacin R, denotado R(A1, A2, ..., An) est constituido por un nombre de relacin R y una lista de atributos A1, ..., An. Cada atributo Ai es el nombre de un rol jugado por el dominio D en el esquema de la relacin R. D se llama el dominio de Ai y se denota dom(Ai). Un esquema relacional se usa para describir una relacin. R es el nombre de esta relacin. El grado de una relacin es el nmero n de atributos del esquema de la relacin. Ejemplos: ESTUDIANTE(Nombre, Rut, Telfono, Direccin, Edad, Carrera, Promnota) tiene grado 7. dom(Nombre) = Nombres dom(Telfono) = Nmeros-telefnicos-locales etc. Def. Una relacin o instancia de relacin r del esquema de relacin R(A1, A2, ..., An), denotado tambin como r(R) es un conjunto de n-tuplas r = {t1, t2, ..., tm}. Cada n-tupla t es una lista ordenada de n valores t = <v1, ..., vn>, donde cada valor vi, i <= i <= n, es un elemento de dom(Ai) o es un valor nulo. Ejemplo: ESTUDIANT Nombre Rut E Telfon Direcci Eda Carrer Prom o n d a -nota
13

BASES DE DATOS

MIS 308

Benjam n 13.245.62 224Gonzle 2-1 4211 z Sergio Soto ... 12.341.22 nulo 8-5 ... ...

Rosas 3241

19

Plan 4.8 comn Ing. Ind. ...

Gay214 20 2 ... ...

5.1 ...

Cada tupla representa una entidad de estudiante en particular. La definicin de relacin puede replantearse as: Una relacin r(R) es un subconjunto del producto cartesiano de los dominios que definen r: r(R) <e> (dom(A1) x dom(A2) x ... x dom(An)) El nmero total de tuplas en el producto cartesiano es: |dom(A1)| * |dom(A2)| * ... * |dom(An)| Una instancia de relacin refleja slo las tuplas vlidas que representa un estado particular del mundo real. A medida que el mundo real cambia, tambin lo hace la relacin, transformndose en otro estado de relacin (el esquema R es relativamente esttico y no cambia excepto muy pocas veces). Notacin Un esquema de relacin R de grado n se denota R(A1, A2, ..., An) Una n-tupla t en una relacin r(R) se denota t = <v1, ..., v2>, donde vi es el valor correspondiente del atributo Ai t[Ai] se refiere al valor vi en t para el atributo Ai t[Au, Aw, ..., Az] donde Au, Aw, ..., Az es una lista de atributos de R, se refiere a las subtuplas de valores <vu, vw, ..., vz> de t correspondientes a los atributos especificados en la lista Las letras Q, R, S denotan nombres de relacin Las letras q, r, s denotan estados de relacin Las letras t, u, v denotan tuplas Los nombres de atributos se califican con el nombre de relacin a la cual pertenecen. Por ejemplo, ESTUDIANTE.Nombre o ESTUDIANTE.Edad
14

BASES DE DATOS

MIS 308

Para la tupla t = <Benjamn Gonzlez, 13.245.622-1, 224-4211, Rosas 3241, 19, Plan comn, 4.8>, tenemos t[Nombre] = <Benjamn Gonzlez>, t[Rut, Prom-notas, Edad] = <13.245.622-1, 4.8, 19> Restricciones Las restricciones de dominios especifican que el valor de cada atributo A debe ser un valor atmico del dominio dom(A). Una relacin se define como un conjunto de tuplas. Por definicin todos los elementos de un conjunto son distintos. Luego todas las tuplas de una relacin deben ser distintas. Esto implica que dos tuplas no pueden tener la misma combinacin de valores para todos sus atributos. Pero puede haber otros subconjuntos de atributos de un esquema de relacin R con la propiedad de que no haya dos tuplas en una instancia de relacin r de R que tengan la misma combinacin de valores para esos atributos. Supongamos que denotamos tal subconjunto de atributos por SC. Entonces para cada dos tuplas distintas t1 y t2 en una instancia de relacin r de R, tenemos la restriccin: t1[SC] <e> t2[SC] Cualquier conjunto de atributos SC es denominado super llave del esquema de relacin R. Cada relacin tiene al menos una super llave (el conjunto de todos sus atributos). Una llave o clave K de un esquema de relacin R es una sper llave de R con la propiedad adicional de que al sacar cualquier atributo A de K deja un conjunto de atributos K' que no es sper llave de R (una clave es una sper llave mnima). El valor de un atributo clave se usa para identificar unvocamente una tupla en una relacin. El hecho que un conjunto de atributos constituya una clase es una propiedad del esquema de la relacin, y es invariante en el tiempo. En general, un esquema de relacin puede tener ms de una clave, y en ese caso, cada una de las llaves es una llave candidata. Una de las llaves candidatas se designa como llave primaria de la relacin. Usamos la convencin de que los atributos que forman la llave primaria de un esquema de relacin se subrayan.

Base de datos relacional

15

BASES DE DATOS

MIS 308

Un esquema de Base de Datos (DB) relacional es un conjunto de esquemas de relacin S = (R1, R2, ..., Rm) y un conjunto RI de restricciones de integridad. Una instancia de DB relacional DB de S es un conjunto de instancias de relacin DB = {r1, ..., rn} tal que cada ri es una instancia de Ri y tal que las relaciones ri satisfacen las restricciones de integridad especificadas en RI. Ejemplo: EMPLEADO NPIL APP APM RU FNA DIRECCI SEX SUEL A AT AT T C ON O DO DEPARTAMENTO DNOMBRE DNUMERO RUTGERENTE GERFECHAINIC UBICACIONES_DEPTO DNUMERO DUBICACION PROYECTO PNOMBRE PNUMERO PUBICACION DNUM TRABAJA_EN ERUT PNO HORAS CARGA ERUT NOMBRE_CARGA SEXO FNAC PARENTESCO RUTSUPE NDEP RV TO

Los siguientes datos corresponden a una instancia de la base de datos. EMPLE NPIL APP APM RUT ADO A AT AT FN DIREC SE SUE RUTSU NDE AC CION XO LDO PERV PTO

16

BASES DE DATOS

MIS 308

Juan

9Pr Garc 1234 Toesca M 1ez a 5678 965 55

120

333445 5 55 987654 4 32 888665 4 55 888665 5 55

19Zela 9998 Blanco Roa Alicia F 7ya 8777 2120 58 20- Mapoc Juan Bes Mart 9876 F 6- ho a a nez 5432 31 2540 83334 Condell Franc M Cea Daza 12221 4555 isco 45 10Ra Sala 8886 Vitacur Jaime M 11mos s 6555 a 1015 30

105

240

310

360

nulo

DEPARTAMENT DNOMBRE O Of. Central

DNUMER RUTGERENT GERFECHAINI O E C 1 88866555 98765432 33344555 19-6-71 1-1-85 22-5-78

Administraci 4 n Investigacin 5

UBICACIONES_DEPTO DNUMERO DUBICACION 1 4 5 5 Providencia uoa La Florida Pirque

PROYECTO PNOMBRE

PNUMERO PUBICACION DNUM

17

BASES DE DATOS

MIS 308

Producto X Producto Y

1 2

La Florida Pirque uoa Providencia

5 5 4 1

Computarizacin 10 Reorganizacin 20

TRABAJA_EN ERUT

PNO HORAS 32.5 7.5 10.0 10.0 10.0 15.0 nulo

12345678 1 12345678 2 33344555 2 99988777 10 98765432 10 98765432 20 88866555 20

CARGA ERUT

NOMBRE_CARGA SEXO FNAC F M F M F 5-4-86

PARENTESCO Hija

33344555 Alicia 33344555 Teodoro 33344555 Ximena 98765432 Rodolfo 12345678 Alicia

25-10-83 Hijo 3-5-54 28-2-32 5-5-57 Cnyuge Cnyuge cnyuge

Observemos que DNUMERO es el mismo para DEPARTAMENTO y PROYECTO. Pero el mismo concepto se llama DNO en EMPLEADO y DNUM en PROYECTO No hay problema. La restriccin de integridad de entidad establece que ningn valor de llave primaria puede ser nulo. Esto es porque ellas identifican tuplas de la relacin.
18

BASES DE DATOS

MIS 308

La restriccin de integridad referencial se especifica entre dos relaciones y se usa para mantener la consistencia entre tuplas de las dos relaciones. Informalmente, una tupla en una relacin que hace referencia a otra relacin debe referirse a una tupla existente en esa relacin. Por ejemplo, NDEPTO de EMPLEADO debe coincidir con el DNUMERO de alguna tupla de la relacin DEPARTAMENTO. Para una definicin formal, necesitamos el concepto de llave fornea. Def. Un conjunto de atributos LF en el esquema de relacin R1 es una llave fornea de R1 si satisface las siguientes reglas: 1. Los atributos en LF tienen el mismo dominio que los atributos de la llave primaria LP de otro esquema de relacin R2. Los atributos LF se dicequereferencianlarelacinR2. 2. Un valor de LF en una tulpa t1 de R1 ya sea es nulo, o ocurre como un valor de LP para alguna tupla t2 de R2. Ejemplo: NDEPTO en una tupla t1 de EMPLEADO debe coincidir con el valor de una llave primaria DNUMERO en alguna tupla t2 de la relacin DEPARTAMENTO, o el valor de DNO puede ser nulo si el empleado no pertenece a un departamento. Las restricciones anteriores no consideran las restricciones semnticas que quizs puedan especificarse y sostenerse en una BD relacional. Por ejemplo, "el sueldo de un empleado no puede exceder el de su supervisor", "el nmero mximo de horas que puede trabajar un empleado en todos los proyectos es 56". Operaciones de actualizacin La operacin Insert provee una lista de valores de atributos para una nueva tupla t que se va a insertar en una relacin R. Ejemplo: Insert <"Cecilia", "Rodrguez", "Kolonsky", "67767898", "5-4-50", "Ejrcito 565", "F", 100, nulo, "4"> en EMPLEADO. Esta insercin satisface todas las restricciones, as que es aceptable. Insert <"Alicia", "Zelaya", "Roa", "99988777", "15-3-50", "Gay 1315", "F", 120, "98765432", "4"> en EMPLEADO. Viola la restriccin de clave porque otra tupla con el mismo Rut ya existe en la relacin. Inaceptable. Insert <"Cecilia", "Rodrguez", "Kolonsky", nulo, "5-4-50", "Ejrcito 565", "F", 100, nulo, 4> en EMPLEADO. Viola la restriccin de integridad (nulo para clave primaria Rut). Inaceptable. Insert <"Cecilia", "Rodrguez", "Kolonsky", "67767898", "5-4-50", "Ejrcito
19

BASES DE DATOS

MIS 308

565", "F", 100, "98765432", 7> en EMPLEADO. Viola la restriccin de integridad referencial porque no existe una tupla en DEPARTAMENTO con DNUMERO = 7. El DBMS puede hacer dos opciones cuando hay violacin de restricciones. Una es rechazar la insercin. La otra es intentar corregir la razn de rechazo de la insercin. Operaciones de borrado La operacin Delete borra tuplas de una relacin. Es posible que se viole la integridad referencial cuando una tupla que se quiere borrar es referenciada por las llaves forneas de otras tuplas de la BD. Las tuplas a borrar se especifican a travs de condiciones sobre los atributos de la relacin. Ejemplos: Delete tupla con ERUT = "99988777" AND PNO = 10 en la relacin TRABAJA_EN. Esta operacin es aceptable. Delete tupla con RUT = "99988777" en la relacin EMPLEADO. Inaceptable porque dos tuplas en TRABAJA_EN se refieren a esta tupla. Si se borra, hay violaciones a la integridad referencial. Hay tres opciones con respecto a una operacin de borrado que causa una violacin. La primera es rechazar la operacin. La segunda es intentar propagar el borrado. Una tercera opcin es modificar los valores de los atributos referenciantes que causan la violacin (cada uno de estos valores puede ser puesto en nulo o cambiado para referenciar otra tupla vlida). Hay que observar que si un atributo referenciante que causa una violacin, es parte de la llave primaria, no puede ser nulo, pues se violara la integridad de entidad. Operaciones de modificacin La operacin Modify se usa para cambiar valores a uno o ms atributos en una tupla (o tuplas) de una relacin R. Es necesario especificar una condicin sobre los atributos de R para seleccionar la o las tuplas a modificar. Ejemplos: Modify SUELDO de la tupla de EMPLEADO con RUT = "99988777" a 135. Aceptable. Modify NDEPTO de la tupla de EMPLEADO con RUT = "99988777" a 1. Aceptable.

20

BASES DE DATOS

MIS 308

Modify NDEPTO de la tupla de EMPLEADO con RUT = "99988777" a 7. Inaceptable pues viola la integridad referencial. Modify RUT de la tupla de EMPLEADO con RUT = "99988777" a "98765432". Inaceptable pues viola restricciones de clave primaria e integridad-referencial. El modificar un atributo que no es llave primaria ni llave fornea no tiene problemas. El modificar una llave primaria es similar a borrar una tupla e insertar otra en su lugar. Por tanto, es relevante la discusin anterior (Insert y Delete). Si se modifica un atributo de una llave fornea, el Sistema Administrador de Base de Datos ( DBMS ) debe asegurarse que el nuevo valor se refiere a una tupla existente en la relacin referenciada. Terminologa relacional equivalente

Trabajo (Cdigo, Nombre, Posicin, Salario), donde Cdigo es la Clave Primaria

Relacin = tabla o archivo Tupla = registro, fila o rengln Atributo = columna o campo Clave = llave o cdigo de identificacin Clave Candidata = superclave mnima Clave Primaria = clave candidata elegida Clave Ajena = clave externa o clave fornea Clave Alternativa = clave secundaria Dependencia Multivaluada = dependencia multivalor RDBMS = Del ingls Relational Data Base Manager System que significa, Sistema Gestor de Bases de Datos Relacionales.

21

BASES DE DATOS

MIS 308

1FN = Significa, Primera Forma Normal o 1NF del ingls First Normal Form. Los trminos Relacin, Tupla y Atributo derivan de las matemticas relacionales, que constituyen la fuente terica del modelo de base de datos relacional. Todo atributo en una tabla tiene un dominio, el cual representa el conjunto de valores que el mismo puede tomar. Una instancia de una tabla puede verse entonces como un subconjunto del producto cartesiano entre los dominios de los atributos. Sin embargo, suele haber algunas diferencias con la analoga matemtica, dado que algunos RDBMS permiten filas duplicadas, entre otras cosas. Finalmente, una tupla puede razonarse matemticamente como un elemento del producto cartesiano entre los dominios.

4.2 Solucin de problemas

Redundancia e inconsistencia de datos. Puesto que los archivos que mantienen almacenada la informacin son creados por diferentes tipos de programas de aplicacin existe la posibilidad de que si no se controla detalladamente el almacenamiento, se pueda originar un duplicado de informacin, es decir que la misma informacin sea ms de una vez en un dispositivo de almacenamiento. Esto aumenta los costos de almacenamiento y acceso a los datos, adems de que puede originar la inconsistencia de los datos - es decir diversas copias de un mismo dato no concuerdan entre si -, por ejemplo: que se actualiza la direccin de un cliente en un archivo y que en otros archivos permanezca la anterior. Dificultad para tener acceso a los datos. Un sistema de base de datos debe contemplar un entorno de datos que le facilite al usuario el manejo de los mismos. Supngase un banco, y que uno de los gerentes necesita averiguar los nombres de todos los clientes que viven dentro del cdigo postal 78733 de la ciudad. El gerente pide al departamento de procesamiento de datos que genere la lista correspondiente. Puesto que esta situacin no fue prevista en el diseo del sistema, no existe ninguna aplicacin de consulta que permita este tipo de solicitud, esto ocasiona una deficiencia del sistema. Aislamiento de los datos. Puesto que los datos estn repartidos en varios archivos, y estos no pueden tener diferentes formatos, es difcil escribir nuevos programas de aplicacin para obtener los datos apropiados. Anomalas del acceso concurrente.
22

BASES DE DATOS

MIS 308

Para mejorar el funcionamiento global del sistema y obtener un tiempo de respuesta ms rpido, muchos sistemas permiten que mltiples usuarios actualicen los datos simultneamente. En un entorno as la interaccin de actualizaciones concurrentes puede dar por resultado datos inconsistentes. Para prevenir esta posibilidad debe mantenerse alguna forma de supervisin en el sistema. Problemas de seguridad. La informacin de toda empresa es importante, aunque unos datos lo son ms que otros, por tal motivo se debe considerar el control de acceso a los mismos, no todos los usuarios pueden visualizar alguna informacin, por tal motivo para que un sistema de base de datos sea confiable debe mantener un grado de seguridad que garantice la autentificacin y proteccin de los datos. En un banco por ejemplo, el personal de nminas slo necesita ver la parte de la base de datos que tiene informacin acerca de los distintos empleados del banco y no a otro tipo de informacin. Problemas de integridad. Los valores de datos almacenados en la base de datos deben satisfacer cierto tipo de restricciones de consistencia. Estas restricciones se hacen cumplir en el sistema aadiendo cdigos apropiados en los diversos programas de aplicacin.

Lo anterior es originado por: Redundancia Anomalas o Actualizacin o Insercin o Borrado Creadas durante: Mantenimiento Creacin Modificacin

23

BASES DE DATOS

MIS 308

Donde la Solucin es: Normalizacin

4.3 Normalizacin: 1NF, 2NF, 3FN, BCNF

Si nunca antes hemos odo hablar de la "normalizacin de datos", no debemos temer. Mientras que la normalizacin puede parecer un tema complicado, nos podemos beneficiar ampliamente al entender los conceptos ms elementales de la normalizacin. Una de las formas ms fciles de entender esto es pensar en nuestras tablas como hojas de clculo. Por ejemplo, si quisiramos seguir la pista de nuestra coleccin de CDs en una hoja de clculo, podramos disear algo parecido a lo que se muestra en la siguiente tabla.

+------------+-------------+--------------+ .. +--------------+ | lbum | track1 | track2 | | track10 | +------------+-------------+--------------+ .. +--------------+

Esto parece razonable. Sin embargo el problema es que el nmero de pistas que tiene un CD vara bastante. Esto significa que con este mtodo tendramos que tener una hoja de clculo realmente grande para albergar todos los datos, que en los peores casos podran ser de hasta 20 pistas. Esto en definitiva no es nada bueno. Uno de los objetivos de una estructura de tabla normalizada es minimizar el nmero de "celdas vacas". El darnos cuenta de que cada lista de CDs tiene un conjunto fijo de campos (ttulo, artista, ao, gnero) y un conjunto variable de atributos (el nmero de pistas) nos da una idea de cmo dividir los datos en mltiples tablas que luego podamos relacionar entre s. Mucha gente no esta familiarizada con el concepto "relacional", de manera sencilla esto significa, que grupos parecidos de informacin son almacenados en distintas tablas que luego pueden ser "juntadas" (relacionadas) basndose en los datos que tengan en comn. Es necesario que al realizar la estructura de una base de datos, esta sea flexible. La flexibilidad est en el hecho que podemos agregar datos al sistema posteriormente sin tener que rescribir lo que ya tenemos. Por ejemplo, si quisiramos agregar la informacin de los artistas de cada lbum, lo nico que tenemos que hacer es crear una tabla artista que
24

BASES DE DATOS

MIS 308

est relacionada a la tabla lbum de la misma manera que la tabla pista. Por lo tanto, no tendremos que modificar la estructura de nuestras tablas actuales, simplemente agregar la que hace falta. La eficiencia se refiere al hecho de que no tenemos duplicacin de datos, y tampoco tenemos grandes cantidades de "celdas vacas". El objetivo principal del diseo de bases de datos es generar tablas que modelan los registros en los que guardaremos nuestra informacin. Es importante que esta informacin se almacene sin redundancia para que se pueda tener una recuperacin rpida y eficiente de los datos. A travs de la normalizacin tratamos de evitar ciertos defectos que nos conduzcan a un mal diseo y que lleven a un procesamiento menos eficaz de los datos. Podramos decir que estos son los principales objetivos de la normalizacin:

Controlar la redundancia de la informacin. Evitar prdidas de informacin. Capacidad para representar toda la informacin. Mantener la consistencia de los datos. La normalizacin es una tcnica para disear la estructura lgica de los datos de un sistema de informacin en el modelo relacional, desarrollada por E. F. Codd en 1972. Es una estrategia de diseo de abajo a arriba: se parte de los atributos y stos se van agrupando en relaciones (tablas) segn su afinidad. Aqu no se utilizar la normalizacin como una tcnica de diseo de bases de datos, sino como una etapa posterior a la correspondencia entre el esquema conceptual y el esquema lgico, que elimine las dependencias entre atributos no deseadas. Las ventajas de la normalizacin son las siguientes:

Evita anomalas en inserciones, modificaciones y borrados. Mejora la independencia de datos. No establece restricciones artificiales en la estructura de los datos. Uno de los conceptos fundamentales en la normalizacin es el de dependencia funcional. Una dependencia funcional es una relacin entre atributos de una misma relacin (tabla). Si relacin por , se dice que e son atributos de la (se denota ( e

es funcionalmente dependiente de tiene asociado un solo valor de

25

) si cada valor de

BASES DE DATOS

MIS 308

pueden constar de uno o varios atributos). A

se le denomina

determinante, ya que determina el valor de . Se dice que el atributo es completamente dependiente de si depende funcionalmente de y no depende de ningn subconjunto de . La dependencia funcional es una nocin semntica. Si hay o no dependencias funcionales entre atributos no lo determina una serie abstracta de reglas, sino, ms bien, los modelos mentales del usuario y las reglas de negocio de la organizacin o empresa para la que se desarrolla el sistema de informacin. Cada dependencia funcional es una clase especial de regla de integridad y representa una relacin de uno a muchos. En el proceso de normalizacin se debe ir comprobando que cada relacin (tabla) cumple una serie de reglas que se basan en la clave primaria y las dependencias funcionales. Cada regla que se cumple aumenta el grado de normalizacin. Si una regla no se cumple, la relacin se debe descomponer en varias relaciones que s la cumplan. La normalizacin se lleva a cabo en una serie pasos. Cada paso corresponde a una forma normal que tiene unas propiedades. Conforme se va avanzando en la normalizacin, las relaciones tienen un formato ms estricto (ms fuerte) y, por lo tanto, son menos vulnerables a las anomalas de actualizacin. El modelo relacional slo requiere un conjunto de relaciones en primera forma normal. Las restantes formas normales son opcionales. Sin embargo, para evitar las anomalas de actualizacin, es recomendable llegar al menos a la tercera forma normal. Uno de los retos en el diseo de la base de datos es el de obtener una estructura estable y lgica tal que: 1. El sistema de base de datos no sufra de anomalas de almacenamiento. 2. El modelo lgico pueda modificarse fcilmente para admitir nuevos requerimientos. Una base de datos implantada sobre un modelo bien diseado tiene mayor esperanza de vida aun en un ambiente dinmico, que una base de datos con un diseo pobre. En promedio, una base de datos experimenta una reorganizacin general cada seis aos, dependiendo de lo dinmico de los requerimientos de los usuarios. Una base de datos bien diseada tendr un buen desempeo aunque aumente su tamao, y ser lo suficientemente flexible para incorporar nuevos requerimientos o caractersticas adicionales.

26

BASES DE DATOS

MIS 308

Existen diversos riesgos en el diseo de las bases de datos relacionales que afecten la funcionalidad de la misma, los riesgos generalmente son la redundancia de informacin y la inconsistencia de datos. La normalizacin es el proceso de simplificar la relacin entre los campos de un registro. Por medio de la normalizacin un conjunto de datos en un registro se reemplaza por varios registros que son ms simples y predecibles y, por lo tanto, ms manejables. La normalizacin se lleva a cabo por cuatro razones: Estructurar los datos de forma que se puedan representar las relaciones pertinentes entre los datos. Permitir la recuperacin sencilla de los datos en respuesta a las solicitudes de consultas y reportes. Simplificar el mantenimiento de los datos actualizndolos, insertndolos y borrndolos. Reducir la necesidad de reestructurar o reorganizar los datos cuando surjan nuevas aplicaciones. En trminos ms sencillos la normalizacin trata de simplificar el diseo de una base de datos, esto a travs de la bsqueda de la mejor estructuracin que pueda utilizarse con las entidades involucradas en ella. Pasos de la normalizacin: 1. Descomponer todos bidimensionales. los grupos de datos en registros

2. Eliminar todas las relaciones en la que los datos no dependan completamente de la llave primaria del registro. 3. Eliminar todas las relaciones que contengan dependencias transitivas. La teora de normalizacin tiene como fundamento el concepto de formas normales; se dice que una relacin est en una determinada forma normal si satisface un conjunto de restricciones. Primera y segunda formas normales. Formas normales.

27

BASES DE DATOS

MIS 308

Son las tcnicas para prevenir las anomalas en las tablas. Dependiendo de su estructura, una tabla puede estar en primera forma normal, segunda forma normal o en cualquier otra. Relacin entre las formas normales:

Primera forma normal. Definicin formal: Una relacin R se encuentra en 1FN si y solo s por cada rengln columna contiene valores atmicos. Abreviada como 1FN, se considera que una relacin se encuentra en la primera forma normal cuando cumple lo siguiente: 1. Las celdas de las tablas poseen valores simples y no se permiten grupos ni arreglos repetidos como valores, es decir, contienen un solo valor por cada celda. 2. Todos los ingresos en cualquier columna (atributo) deben ser del mismo tipo. 3. Cada columna debe tener un nombre nico, el orden de las columnas en la tabla no es importante. 4. Dos filas o renglones de una misma tabla no deben ser idnticas, aunque el orden de las filas no es importante. Por lo general la mayora de las relaciones cumplen con estas caractersticas, as que podemos decir que la mayora de las relaciones se encuentran en la primera forma normal. Para ejemplificar como se representan grficamente las relaciones en primera forma normal consideremos la relacin alumno cursa materia cuyo diagrama E-R es el siguiente:

28

BASES DE DATOS

MIS 308

Como esta relacin maneja valores atmicos, es decir un solo valor por cada uno de los campos que conforman a los atributos de las entidades, ya se encuentra en primera forma normal, grficamente as representamos a las relaciones en 1FN. Segunda forma normal. Para definir formalmente la segunda forma normal requerimos saber que es una dependencia funcional: Consiste en edificar que atributos dependen de otro(s) atributo(s).

Definicin formal: Una relacin R est en 2FN si y solo si est en 1FN y los atributos no primos dependen funcionalmente de la llave primaria. Una relacin se encuentra en segunda forma normal, cuando cumple con las reglas de la primera forma normal y todos sus atributos que no son claves (llaves) dependen por completo de la clave. De acuerdo con est definicin, cada tabla que tiene un atributo nico como clave, esta en segunda forma normal. La segunda forma normal se representa por dependencias funcionales como:

Ntese que las llaves primarias estn representadas con doble cuadro, las flechas nos indican que de estos atributos se puede referenciar a los otros atributos que dependen funcionalmente de la llave primaria.

29

BASES DE DATOS

MIS 308

Tercera forma normal y la forma normal de Boyce Codd. Para definir formalmente la 3FN necesitamos definir dependencia transitiva: En una afinidad (tabla bidimensional) que tiene por lo menos 3 atributos (A,B,C) en donde A determina a B, B determina a C pero no determina a A. Tercera forma normal. Definicin formal: Una relacin R est en 3FN si y solo si esta en 2FN y todos sus atributos no primos dependen no transitivamente de la llave primaria. Consiste en eliminar la dependencia transitiva que queda en una segunda forma normal, en pocas palabras una relacin esta en tercera forma normal si est en segunda forma normal y no existen dependencias transitivas entre los atributos, nos referimos a dependencias transitivas cuando existe ms de una forma de llegar a referencias a un atributo de una relacin. Por ejemplo, consideremos el siguiente caso:

Tenemos la relacin alumno-cursa-materia manejada anteriormente, pero ahora consideramos al elemento maestro, grficamente lo podemos representar de la siguiente manera:

30

BASES DE DATOS

MIS 308

Podemos darnos cuenta que se encuentra graficado en segunda forma normal, es decir que todos los atributos llave estn indicados en doble cuadro indicando los atributos que dependen de dichas llaves, sin embargo en la llave Necono tiene como dependientes a 3 atributos en el cual el nombre puede ser referenciado por dos atributos: Necono y RFC (Existe dependencia transitiva), podemos solucionar esto aplicando la tercera forma normal que consiste en eliminar estas dependencias separando los atributos, entonces tenemos:

Forma normal de Boyce Codd. Determinante: Uno o ms atributos que, de manera funcional, determinan otro atributo o atributos. En la dependencia funcional (A,B)->C, (A,B) son los determinantes.

Definicin formal: Una relacin R esta en FNBC si y solo si cada determinante es una llave candidato.
31

BASES DE DATOS

MIS 308

Denominada por sus siglas en ingles como BCNF; Una tabla se considera en esta forma si y slo s cada determinante o atributo es una llave candidato. Continuando con el ejemplo anterior, si consideramos que en la entidad alumno sus atributos control y nombre nos puede hacer referencia al atributo esp., entonces decimos que dichos atributos pueden ser llaves candidato. Grficamente podemos representar la forma normal de Boyce Codd de la siguiente forma:

Obsrvese que a diferencia de la tercera forma normal, agrupamos todas las llaves candidato para formar una global (representadas en el recuadro) las cuales hacen referencia a los atributos que no son llaves candidato.

4.4 Criterios para normalizar Codd se percat de que existan bases de datos en el mercado las cuales decan ser relacionales, pero lo nico que hacan era guardar la informacin en las tablas, sin estar estas tablas literalmente normalizadas; entonces ste public 12 reglas que un verdadero sistema relacional debera tener, en la prctica algunas de ellas son difciles de realizar. Un sistema podr considerarse "ms relacional" cuanto ms siga estas reglas. Regla No. 1 - La Regla de la informacin Toda la informacin en un RDBMS est explcitamente representada de una sola manera por valores en una tabla. Cualquier cosa que no exista en una tabla no existe del todo. Toda la informacin, incluyendo nombres de tablas, nombres de vistas, nombres de columnas, y los datos de las columnas deben estar almacenados en tablas dentro de las bases de datos. Las tablas que contienen tal informacin constituyen el Diccionario de Datos. Esto significa que todo tiene que estar almacenado en las tablas. Toda la informacin en una base de datos relacional se representa explcitamente en el nivel lgico exactamente de una manera: con
32

BASES DE DATOS

MIS 308

valores en tablas. Por tanto los metadatos (diccionario, catlogo) se representan exactamente igual que los datos de usuario. Y puede usarse el mismo lenguaje (ej. SQL) para acceder a los datos y a los metadatos (regla 4) Regla No. 2 - La regla del acceso garantizado Cada tem de datos debe ser lgicamente accesible al ejecutar una bsqueda que combine el nombre de la tabla, su clave primaria, y el nombre de la columna. Esto significa que dado un nombre de tabla, dado el valor de la clave primaria, y dado el nombre de la columna requerida, deber encontrarse uno y solamente un valor. Por esta razn la definicin de claves primarias para todas las tablas es prcticamente obligatoria.

Regla No. 3 - Tratamiento sistemtico de los valores nulos La informacin inaplicable o faltante puede ser representada a travs de valores nulos. Un RDBMS (Sistema Gestor de Bases de Datos Relacionales) debe ser capaz de soportar el uso de valores nulos en el lugar de columnas cuyos valores sean desconocidos o inaplicables. Regla No. 4 - La regla de la descripcin de la base de datos La descripcin de la base de datos es almacenada de la misma manera que los datos ordinarios, esto es, en tablas y columnas, y debe ser accesible a los usuarios autorizados. La informacin de tablas, vistas, permisos de acceso de usuarios autorizados, etc, debe ser almacenada exactamente de la misma manera: En tablas. Estas tablas deben ser accesibles igual que todas las tablas, a travs de sentencias de SQL (o similar). Regla No. 5 - La regla del sub-lenguaje Integral Debe haber al menos un lenguaje que sea integral para soportar la definicin de datos, manipulacin de datos, definicin de vistas, restricciones de integridad, y control de autorizaciones y transacciones. Esto significa que debe haber por lo menos un lenguaje con una sintaxis bien definida que pueda ser usado para administrar completamente la base de datos. Regla No. 6 - La regla de la actualizacin de vistas
33

BASES DE DATOS

MIS 308

Todas las vistas que son tericamente actualizables, deben ser actualizables por el sistema mismo. La mayora de las RDBMS permiten actualizar vistas simples, pero deshabilitan los intentos de actualizar vistas complejas. Regla No. 7 - La regla de insertar y actualizar La capacidad de manejar una base de datos con operandos simples aplica no slo para la recuperacin o consulta de datos, sino tambin para la insercin, actualizacin y borrado de datos'. Esto significa que las clusulas para leer, escribir, eliminar y agregar registros (SELECT, UPDATE, DELETE e INSERT en SQL) deben estar disponibles y operables, independientemente del tipo de relaciones y restricciones que haya entre las tablas.

Regla No. 8 - La regla de independencia fsica El acceso de usuarios a la base de datos a travs de terminales o programas de aplicacin, debe permanecer consistente lgicamente cuando quiera que haya cambios en los datos almacenados, o sean cambiados los mtodos de acceso a los datos. El comportamiento de los programas de aplicacin y de la actividad de usuarios va terminales debera ser predecible basados en la definicin lgica de la base de datos, y ste comportamiento debera permanecer inalterado, independientemente de los cambios en la definicin fsica de sta. Regla No. 9 - La regla de independencia lgica Los programas de aplicacin y las actividades de acceso por terminal deben permanecer lgicamente inalteradas cuando quiera que se hagan cambios (segn los permisos asignados) en las tablas de la base de datos. La independencia lgica de los datos especifica que los programas de aplicacin y las actividades de terminal deben ser independientes de la estructura lgica, por lo tanto los cambios en la estructura lgica no deben alterar o modificar estos programas de aplicacin. Regla No. 10 - La regla de la independencia de la integridad Todas las restricciones de integridad deben ser definibles en los datos, y almacenables en el catalogo, no en el programa de aplicacin.

34

BASES DE DATOS

MIS 308

Las reglas de integridad 1. 2. Ningn componente de una clave primaria puede tener valores en blanco o nulos. (esta es la norma bsica de integridad). Para cada valor de clave fornea deber existir un valor de clave primaria concordante. La combinacin de estas reglas aseguran que haya Integridad referencial. Regla No. 11 - La regla de la distribucin El sistema debe poseer un lenguaje de datos que pueda soportar que la base de datos est distribuida fsicamente en distintos lugares sin que esto afecte o altere a los programas de aplicacin. El soporte para bases de datos distribuidas significa que una coleccin arbitraria de relaciones, bases de datos corriendo en una mezcla de distintas mquinas y distintos sistemas operativos y que est conectada por una variedad de redes, pueda funcionar como si estuviera disponible como en una nica base de datos en una sola mquina. Regla No. 12 - Regla de la no-subversin Si el sistema tiene lenguajes de bajo nivel, estos lenguajes de ninguna manera pueden ser usados para violar la integridad de las reglas y restricciones expresadas en un lenguaje de alto nivel (como SQL). Algunos productos solamente construyen una interfaz relacional para sus bases de datos No relacionales, lo que hace posible la subversin (violacin) de las restricciones de integridad. Esto no debe ser permitido.

35