Base de Datos

[NataliaAlvarezIspc]

Crear resumen de Base de Datos

[osqui91]

Historia y Evolución de los SGBD

Antes de comenzar a abordar los Sistemas de Gestión de Base de Datos , los invitamos a recorrer una breve lectura en la que se aborda la historia de los mismos.

Orígenes

Los orígenes de las bases de datos se remontan a la Antigüedad donde ya existían bibliotecas y toda clase de registros. Además también se utilizaban para recoger información sobre las cosechas y censos. Posteriormente, el uso de las bases de datos se desarrolló a partir de las necesidades de almacenar grandes cantidades de información o datos. Sobre todo, desde la aparición de las primeras computadoras, el concepto de bases de datos ha estado siempre ligado a la informática.

Posteriormente, en la década de los cincuenta se da origen a las cintas magnéticas, para automatizar la información y hacer respaldos. Esto sirvió para suplir las necesidades de información de las nuevas industrias. Y a través de este mecanismo se empezaron a automatizar información, con la desventaja de que solo se podía hacer de forma secuencial. Cada aplicación utilizaba ficheros de movimientos para actualizar y/o para consultar uno o dos ficheros maestros o, excepcionalmente, más de dos.

Cada vez que se le quería añadir una aplicación que requería el uso de algunos de los datos que ya existían y de otros nuevos, se diseñaba un fichero nuevo con todos los datos necesarios . Para evitar que los programas tuviesen que leer muchos ficheros. A medida que se fueron introduciendo las líneas de comunicación, los terminales y los discos, se fueron escribiendo programas que permitían a varios usuarios consultar los mismos ficheros on-line y de forma simultánea. Estos conjuntos de ficheros interrelacionados, con estructuras complejas y compartidas por varios procesos de forma simultánea , recibieron al principio el nombre de Data Banks, y después, a inicios de los años setenta, el de Data Bases.

El software de gestión de ficheros era demasiado elemental para dar satisfacción a todas estas necesidades. Por ejemplo, el tratamiento de las interrelaciones no estaba previsto, no era posible que varios usuarios actualizaran datos simultáneamente, etc...

Base Management Systems, que aquí denominamos Sistemas de Gestión de BD . En otras palabras, una base de datos es un conjunto estructurado de datos que representa entidades y sus interrelaciones. Una base de datos de un SI es la representación integrada de los conjuntos de entidades instancia correspondientes a las diferentes entidades tipo del SI y de sus interrelaciones. Década de los 60. En esta misma época se dio inicio a las primeras generaciones de bases de datos de red y las bases de datos jerárquicas, ya que era posible guardar estructuras de datos en listas y arboles. Otro de los principales logros de los años sesenta fue la alianza de IBM y American Airlines para desarrollar SABRE, un sistema operativo que manejaba las reservas de vuelos, transacciones e informaciones sobre los pasajeros de la compañía American Airlines.

Década de los 70 – Sistemas Centralizados. Estaban orientados a facilitar la utilización de grandes conjuntos de datos en los que las interrelaciones eran complejas. Estos sistemas trabajaban exclusivamente por lotes . Al aparecer los terminales de teclado, conectados al ordenador central mediante una línea telefónica, se empiezan a construir grandes aplicaciones on-line transaccionales.

Aunque para escribir los programas de aplicación se utilizaban lenguajes de alto nivel como Cobol o PL/I, se disponía también de instrucciones y de subrutinas especializadas para tratar las BD que requerían que el programador conociese muchos detalles del diseño físico, y que hacían que la programación fuese muy compleja. Puesto que los programas estaban relacionados con el nivel físico, se debían modificar continuamente cuando se hacían cambios en el diseño y la organización de la BD. Por lo que respecta a la década de los setenta, Edgar Frank Codd, científico informático ingles conocido por sus aportaciones a la teoría de bases de datos relacionales, definió el modelo relacional a la par que publicó una serie de reglas para los sistemas de datos relacionales a través de su artículo «Un modelo relacional de datos para grandes bancos de datos compartidos». Este hecho dio paso al nacimiento de la segunda generación de los Sistemas Gestores de Bases de Datos.

Como consecuencia de esto, durante la década de 1970, Lawrence J. Codd sobre los sistemas de bases de datos relacionales, desarrolló el Relational Software System, o lo que es lo mismo, lo que actualmente se conoce como Oracle Corporation, desarrollando así un sistema de gestión de bases de datos relacional con el mismo nombre que dicha compañía. Inicialmente no se usó porque tuvo inconvenientes con el rendimiento, no podía competir con las bases de datos jerárquicas y de redes.

Diseño conceptual

En este apartado se estudia el modelo entidad-relación que permite diseñar el esquema conceptual de una BD, y es muy adecuado para las BDs relacionales. Su resultado es un diagrama entidad-relación.

Entidad: Es el menor objeto con significado en una instancia. Por ejemplo, para el diseño de una BD de la secretaría de un centro docente, el alumno con los siguientes datos: DNI = 01234567Z, Nombre y apellidos = Manuel Vázquez Prieto, Teléfono = 91-12345678 Domicilio = Calle del Jazmín 7, 4 Izq. Atributo: Es cada uno de los componentes que determinan una entidad. Atributos monovalorados y multivalorados: Los atributos multivalorados son los que pueden contener más de un valor simultáneamente, y monovalorados a los que sólo pueden contener un valor Atributos simples y compuestos: Un atributo es compuesto cuando puede descomponerse en otros componentes o atributos más pequeños, y simple en otro caso. Clave: Es un atributo o conjunto de atributos cuyos valores identifican unívocamente cada entidad.

La entidad del ejemplo anterior viene determinada por los valores de sus atributos DNI, Nombre y Apellidos, Teléfono, Domicilio y COU. En este caso haremos de teléfono un atributo multivalorado. Por ejemplo, DNI es un atributo clave del tipo de entidad Alumnos.

Esto significa que los valores de la clave no se pueden repetir en el conjunto de entidades. Alumnos.

El concepto de clave distingue tres claves diferentes:

• Superclave: Es cualquier conjunto de atributos que pueden identificar unívocamente a una tupla.

• Clave candidata: Es el menor conjunto de atributos que puede formar clave. Puede haber varias en una tabla.

• ClavePrimaria: Es la clave candidata que distingue el usuario para identificar unívocamente cada tupla.

Tipo de entidad: Es el conjunto de entidades que comparten los mismos atributos. Relación: Es una correspondencia entre dos o más entidades. Se habla de relaciones binarias cuando la correspondencia es entre dos entidades, ternarias cuando es entre tres, y así sucesivamente. Tipos de relación: Representan a todas las posibles relaciones entre entidades del mismo tipo.

Observaciones:

Las relaciones también pueden tener atributos. Por ejemplo, Matrícula puede tener el atributo Nota que indica la nota que el alumno ha obtenido en una asignatura determinada. Es posible que el mismo tipo de entidad aparezca dos o más veces en un tipo de relación. En este caso se asigna un nombre a cada papel que hace el tipo de entidad en el tipo de relación.

Diagrama entidad - relación. El diseño del modelo E-R a partir del análisis inicial no es directo.De un buen diseño depende:

• Eficiencia: Es muy importante en las BD cuando se manejan grandes cantidades de datos.

• Simplicidad del código: Se cometen menos errores.

• Flexibilidad: Se refiere a que el diagrama sea fácil de modificar.

De la especificación del problema de la secretaría se deduce que va ha haber un tipo de entidad alumnos, pero no cuáles son sus atributos. En cambio, sí tiene un DNI asociado, una dirección asociada, etc. {DNI=12345678V, Nomb.Ape=Luis Martínez, Telf.=01234567, Cod=MD, Título=Matemática Discreta, Créditos=9} {DNI=12345678V, Nomb.Ape=Luis Martínez, Telf.=01234567, Cod=IS, Título=Ingeniería del Software, Créditos=X} {DNI=12345678V, Nomb.Ape=Luis Martínez, Telf.=01234567, Cod=LPI, Título=Laboratorio de programación I, Créditos=X}

Las asignaturas son siempre las mismas, con lo que por cada alumno que se matricula en la misma asignatura hay que repetir toda la información: { DNI=12345678V, Nomb.Ape=Luis Martínez, Telf.=01234567, … , Asignaturas={ {Cod=MD, Título=…}, {COD=IS,Título=…}, {Cod=LPI,Título=…} } } { DNI=0000001, Nomb.Ape=Eva Manzano, Telf.=01234567, … , Asignaturas={ {Cod=MD, Título=…}, {COD=IS,Título=…}, {Cod=BDSI,Título=…} } }

Por cada profesor hay que apuntar las asignaturas que imparte. La información de las asignaturas debe estar por tanto relacionada con la de los profesores, pero ya está incluida con los alumnos. Hay que repetir la información de las asignaturas por lo que se consigue más redundancia. No se pueden guardar los datos de una asignatura hasta que no se matricule un alumno en ella. Puede ser que en secretaría quieran meter los datos de las asignaturas antes de empezar el proceso de matrícula: No pueden. Una solución sería incluirlos con los datos de los alumnos vacíos (nulos), lo cual no sería nada aconsejable. Los valores nulos se deben evitar siempre que sea posible.

El primer tipo de relación es Matrícula que relaciona cada alumno con las asignaturas en las que está matriculado. Además, está relación tiene un atributo, nota, que se asocia cada tupla de la relación. El segundo tipo de relación es Supervisa que va de Profesores a Profesores y que incluye los papeles Supervisor y Supervisado. La última es Imparte, que relaciona cada profesor con la asignatura que imparte y el aula en la que da esa asignatura. Aquí también surgen varias posibilidades: a) Hacer dos relaciones binarias. Por ejemplo, profesor con asignatura y asignatura con aula. b) Hacer una relación ternaria entre profesores, aulas y asignaturas. c) Hacer tres relaciones binarias Profesores-Asignaturas, Profesores-Aulas, Asignaturas-Aulas.

El diagrama entidad-relación del ejemplo quedaría como se ilustra a continuación:

Restricciones.

Las restricciones de integridad son propiedades que se asocian a un tipo de entidad o de relación. Las instancias válidas del tipo de entidad o relación son aquellas en las que se verifique el conjunto de restricciones asociadas. Las restricciones son parte del diseño de la base de datos igual que los tipos de entidades o de relaciones.

Una restricción de clave consiste en imponer que un conjunto de atributos sea el que defina unívocamente a una fila de un tipo de entidades. Por ejemplo, en el tipo de entidades Alumnos se puede elegir DNI para identificar a un alumno en concreto, pero no sería conveniente usar el atributo Nombre y apellidos porque es muy posible encontrar a dos personas con los mismos nombres y apellidos. Por motivos de eficiencia conviene que el número de atributos elegidos sea el menor posible. A veces, es posible elegir varios conjuntos de atributos que contengan el mismo número de atributos, pero se suele escoger uno de estos conjuntos como el representativo, que se denomina clave primaria.

Todos estos conjuntos con el menor y mínimo número de atributos se denominan colectivamente como claves candidatas. Leyendo la relación en el sentido contrario diríamos que en un país pueden haber nacido muchas personas . Se refiere a que podamos encontrar cada entidad de un tipo de entidad en la relación que lo liga con otro u otros. Es decir, cada alumno definido en el tipo de entidad Alumnos debemos encontrarlo en la relación Matrícula, relacionado con la asignatura en la que esté matriculado.

En nuestro caso, las BD relacionales, el resultado de esta etapa es un esquema relacional basado en un modelo relacional. Este modelo fue creado por Codd a principios de los 70 al que dotó de una sólida base teórica. El concepto principal de este modelo es la relación o tabla. Es importante no confundir la tabla con las relaciones del modelo E-R.

Aquí las relaciones se aplican tanto a tipos de relaciones como a tipos de entidades. En este modelo no se distingue entre tipos de entidades y tipos de relaciones porque la idea es que una relación o tabla expresa la relación entre los tipos de valores que contiene.

A continuación se introducen los conceptos de este modelo

A continuación se introducen los conceptos de este modelo:

• Entidad. Igual que en el modelo E-R. También se les llama tuplas o filas de la relación.

• Atributo. Igual que en el modelo E-R. También se le llaman campos o columnas de la relación. El dominio de los

atributos tiene que ser simple: no se admiten atributos multivalorados ni compuestos.

• Esquema de una relación. Viene dado por el nombre de la relación y una lista de atributos. Es el tipo de entidad.

• Conjunto de entidades. Relación o tabla.

Paso de un esquema E-R a un esquema relacional. Tipos de entidades Para cada tipo de entidad se crea una relación con el mismo nombre y conjunto de atributos. Por ejemplo, en el caso de la BD de secretaría los tipos de entidades dan lugar a las siguientes relaciones: Alumnos(DNI, Apellidos y Nombre, Domicilio, Teléfono, COU) Asignaturas(Código, Título, Créditos) Profesores(DNI, Apellidos y nombre, Domicilio, Teléfono) Aulas(Edificio, Número) Tipos de relaciones: Para cada tipo de relación R se crea una relación que tiene como atributos:

• Los atributos de la clave primaria de cada tipo de entidad que participa en la relación.

• Los atributos de la propia relación. En ocasiones hay que renombrar atributos para evitar tener varios con el mismo nombre Restricciones de cardinalidad

Claves: Hay dos casos:

1. La relación proviene de un tipo de entidad en el esquema E-R. La clave es la misma que la del tipo de entidad.

2. La relación proviene de un tipo de relación en el esquema E-R.

   Restricciones de cardinalidad: Es posible incorporar este tipo de restricciones de integridad cuando se desean indicar relaciones una a una, una a varias y varias a varias.

Restricciones de integridad: No es el único tipo de restricciones de integridad que aparece automáticamente al traducir un esquema E-R en otro relacional. Hay dos: restricciones de integridad referencial y restricciones de participación total. Las claves y las restricciones de integridad referencial son características que se expresar directamente en la práctica totalidad de los SGBD relacionales.

Restricciones de integridad referencial: Al traducir un tipo de relación R, en cualquier instancia de R se debe cumplir que los valores de los atributos que hereda de una entidad (de su clave primaria) deben aparecer previamente en el conjunto de entidades. Restricciones de participación total: Cuando cada valor de un tipo de entidad debe aparecer en un tipo de relación, como Alumnos en Matrícula, significa que, además de la restricción de integridad referencial comentada en el apartado anterior, se debe cumplir que todo valor de DNI en Alumnos debe aparecer en el atributo DNI de Matrícula.

Cuestiones de diseño.

En ocasiones es posible combinar dos o más tablas en una sola. Generalmente se combinan por motivos de rendimiento.

El valor NULL es un valor que puede contener cualquier atributo, y lo soportan todos los SGBD. Valor desconocido. Por otra parte, ningún atributo que forme parte de una clave puede tomar el valor NULL. Diseño físico.Por ejemplo, dado el ejemplo de personas nacidas en países:

Diseño físico. El objetivo del diseño físico es la generación del esquema físico de la base de datos en el modelo de datos que implementa el SGBD.

Esto incluye la definición sobre el SGBD de las tablas con sus campos, la imposición de todas las restricciones de integridad y la definición de índices. Los índices son estructuras de datos implementadas con ficheros que permiten un acceso más eficaz a los datos. Se organizan con respecto a uno o más campos y guardan sólo la información del valor de la clave y la dirección física a partir de la cual se pueden encontrar registros con ese valor. El rendimiento de una base de datos depende fundamentalmente de las operaciones de lectura y escritura en disco.

Como las tablas generalmente no caben todas en la memoria principal, en general es necesario leer los datos del disco. Cuantos menos datos se lean o escriban en disco mejor será el rendimiento. Internamente, cuando el SGBD necesita buscar un registro según un valor de un campo sobre el que se ha definido un índice para resolver alguna consulta, busca el valor en el índice, consulta la dirección del registro adjunto y a continuación busca en el fichero de datos el registro. Esto es más rápido que hacer una búsqueda secuencial en el fichero de datos. Por un lado porque los índices no requieren en general una exploración secuencial de sus registros hasta encontrar el valor deseado, sino que se organizan como estructuras que permiten localizar el valor en menos tiempo. Por otra parte, si hay alternativas, siempre es mejor definir índices para los campos de menor tamaño, ya que cuanto más pequeño sea el campo clave, más pequeño será el índice y se necesitarán menos operaciones de lectura del índice. Además de las restricciones de integridad definidas por las claves, las restricciones de cardinalidad y las de participación total estudiadas anteriormente, se tratan las restricciones de los dominios, la integridad referencial, las dependencias funcionales y las dependencias multivaloradas. Las restricciones de integridad proporcionan un medio de asegurar que las modificaciones hechas a la base de datos por los usuarios autorizados no provoquen la pérdida de la consistencia de los datos.

Restricciones de integridad.

Además de las restricciones deintegridad definidas por las claves, las restricciones de cardinalidad y las de participación total estudiadas anteriormente, setratan las restricciones de los dominios, la integridad referencial, las dependencias funcionales y las dependencias multivaloradas. Las restricciones de integridad proporcionan un medio de asegurar que las modificaciones hechas a la base de datos por los usuarios autorizados no provoquen la pérdida de la consistencia de los datos. Protegen a la base de datos contra los daños accidentales Los tipos de restricciones de integridad en una base de datos se pueden resumir como sigue: • Claves. • Cardinalidad de la relación. • Restricciones de los dominios. • Integridad referencial. • Participación total. • Dependencias funcionales. • Otras restricciones

Restricciones de los dominios.

Las restricciones de los dominios son la forma más simple de restricción de integridad. Se especifica para cada atributo un dominio de valores posibles. Una definición adecuada de las restricciones de los dominios no sólo permite verificar los valores introducidos en la base de datos sino también examinar las consultas para asegurarse de que tengan sentido las comparaciones que hagan. La cláusula check permite especificar un predicado que debe satisfacer cualquier valor asignado a una variable cuyo tipo sea el dominio. Por ejemplo:

Restricciones de existencia.

Dentro de las restricciones de los dominios, un tipo especial de restricción que se puede aplicar a cualquier dominio es la restricción de existencia. De manera predeterminada, los atributos que formen parte de la clave primaria tienen esta restricción impuesta. Para declarar esta restricción en la definición de la tabla se usaría NOT NULL después del nombre del atributo y su dominio.

Restricciones de unicidad.

Otro tipo especial de restricción que se puede aplicar a cualquier dominio es la restricción de unicidad. Esta restricción evita la aparición de valores duplicados en las columnas .

Restricciones de integridad referencial.

La integridad referencial permite asegurar que un valor que aparece en una relación para un conjunto de atributos determinado aparezca también en otra relación para ese mismo conjunto de atributos. Este tipo de restricciones se denota simplificadamente: Relación1.(Atributo1-1,...,Atributo1-N) ⊆ Relación2.(Atributo2-1,...,Atributo2-N)

El conjunto de atributos {Atributo1-1,...,Atributo1-N} se denomina clave externa, mientras que el conjunto de atributos {Atributo2-1,...,Atributo2-N} es la clave primaria de Relación2. El sistema, por su parte, puede asegurar la imposición de estas restricciones de integridad, evitando la aparición de valores que las violen. Se distinguen tres casos:

• Al insertar una tupla es necesario comprobar que haya otra con los valores de la clave externa igual a los de sus atributos clave.

• Al borrar una tupla de R el sistema debe calcular el conjunto de tuplas de las otras relaciones que hacen referencia a R. Si este conjunto no es el conjunto vacío, o bien se rechaza la orden borrar como error, o bien se deben borrar las todas las tuplas que hacen referencia a R.

• Actualizar. Hay que considerar dos casos: las actualizaciones de la relación que realiza la referencia (r2) y las actualizaciones de la relación a la que se hace referencia (r1).

Dependecias funcionales.

Una dependencia funcional es una propiedad semántica de un esquema de relación que impone el diseñador. Determina el valor de un conjunto de atributos a partir del valor de otro conjunto de atributos. Por ejemplo, en la siguiente relación se combinan los datos de los empleados, como su código de identificación y nombre, y de los centros a los que están adscritos, como la dirección y el teléfono. En este ejemplo se muestra gráficamente que el valor del conjunto de campos DirecciónC y TeléfonoC depende del valor del campo Centro. En concreto, a un centro en particular le corresponden unívocamente una dirección y un teléfono

Disparadores.

Un disparador es una orden que el sistema ejecuta de manera automática como efecto secundario de la modificación de la base de datos. Un ejemplo que se aplica a la imposición de restricciones de integridad sería la implementación de la detección de la violación de las dependencias funcionales.

Normalización. La traducción del esquema conceptual al lógico no es única. Es necesario contar con una medida de la calidad de la agrupación de los atributos en relaciones. Como herramienta principal se usan las dependencias funcionales para agrupar los atributos en esquemas de relación, que se dice que se encuentran en una determinada forma normal. Un objetivo del diseño de bases de datos relacionales es agrupar atributos en relaciones de forma que se reduzca la redundancia de datos y así el espacio de almacenamiento necesario.

Redundancia de datos.

Un objetivo del diseño de bases de datos relacionales es agrupar atributos en relaciones de forma que se reduzca la redundancia de datos y así el espacio de almacenamiento necesario. Por ejemplo, los siguientes dos esquemas Empleados(Id_empleado, NombreP, DirecciónP, Puesto, Salario, Centro) Centros(NombreC, DirecciónC, Teléfono) contienen la misma información que el siguiente: Empleados_Centros(Id_empleado, NombreP, DirecciónP, Puesto, Salario, NombreC, DirecciónC, Teléfono).

La relación Empleados_Centros presenta redundancia de datos porque se repite para cada empleado la información asociada al centro. Las relaciones con datos redundantes presentan diferentes anomalías de actualización: son las anomalías de inserción, borrado y modificación

Anomalías de actualización.

• Anomalías de inserción: En primer lugar, cuando se inserta una nueva fila sin respetar las dependencias funcionales. En segundo lugar, la imposibilidad de añadir nuevos datos para el consecuente de la dependencia funcional sin que exista un antecedente para ella. En el ejemplo anterior no se puede dar de alta un centro a menos que exista un empleado destinado en él.

• Anomalías de modificación: Se produce cuando se modifican las columnas con datos redundantes de sólo un subconjunto de las filas con el mismo dato.

• Anomalías de eliminación: Se produce cuando se eliminan todas las filas en las que aparecen los datos redundantes por lo que se pierde los datos de la dependencia funcional.

Formas normales y normalización.

La forma normal de una relación se refiere a la mejor forma normal que satisface un esquema de relación indicando así el grado hasta el que se ha normalizado. La indicación del grado de calidad de un esquema de relación se refiere en general en el contexto global del esquema de la base de datos relacional, es decir, en el conjunto de todos los esquemas de relación de la base de datos. Dos propiedades que se deben cumplir para poder asegurarlo son: • La propiedad de preservación de dependencias, que asegura que las dependencias funcionales originales se mantienen en algún esquema de relación después de la descomposición. • La propiedad de la posibilidad de reproducir la información de la tabla antes de su descomposición a partir de las tablas resultado de ella. Las formas normales más habituales, por orden ascendente de exigencia de las propiedades deseadas, son: Primera (1FN) Segunda (2FN) Tercera (3FN) Boyce/Codd (FNBC)

Primera forma normal.

Actualmente se considera como parte de la definición formal de relación, porque establece que los dominios de los atributos sólo pueden ser atómicos, para evitar atributos multivalorados, compuestos y sus combinaciones. Por ejemplo, si se asume que en la entidad Centros, un centro puede tener más de un teléfono, podríamos tener una representación como la siguiente:

Hay tres posibilidades de representar la entidad parasatisfacer la primera forma normal:

• Eliminar el atributo Teléfonos y crear una nueva relación que asocie en cada fila un centro con un teléfono. La clave de la primera relación debe formar parte de la clave de la segunda relación.

• Ampliar la clave de la relación de manera que incluya al atributo multivalorado. Presenta como inconveniente añadir una nueva relación al esquema de la base de datos y redundancia.

• Si se conoce la cardinalidad máxima del atributo multivalorado, se pueden crear tantas columnas como la cardinalidad máxima. Presenta como inconveniente el uso de valores Null.

Si el atributo multivalorado es compuesto, como es el caso de representar varias direcciones para un empleado: Empleados(Id_empleado, NombreE, {Direcciones(Calle, Ciudad, CódigoPostal)}) Esta relación se puede descomponer en dos: Empleados(Id_empleado, NombreE) DireccionesE(Id_empleado, Calle, Ciudad, CódigoPostal)

Segunda forma normal.

En el ejemplo a continuación se puede observar que existen anomalías de actualización causadas por las dependencias funcionales DF2 y DF3, ya que como sus antecedentes no son clave, puede haber varias filas con el mismo consecuente. Se usa una notación gráfica para la expresión de las dependencias funcionales. Así:

Se dice que una relación está en segunda forma normal si cada atributo que no forme parte de la clave primaria depende funcional y completamente de cada clave. Un esquema que no se encuentre en segunda forma normal puede traducirse en varios esquemas que sí lo estén.

Hay que observar que este procedimiento asegura que el resultado está, al menos, en segunda forma normal.

Tercera forma normal.

En el ejemplo a continuación se puede observar que existen anomalías de actualización causadas por la dependencia funcional Sin embargo, este esquema está en segunda forma normal porque los dos últimos atributos, que son los que causan las anomalías, dependen completa del único atributo que forma la clave primaria.

La tercera forma normal se basa en el concepto de dependencia funcional transitiva. En el ejemplo anterior, DF3 es una dependencia funcional transitiva:

El procedimiento para normalizar esta relación consiste en descomponerla en los atributos definidos por la dependencia funcional responsable de la transitividad. . En el ejemplo anterior, el resultado de la descomposición es:

Forma normal de Boyce-Codd

La forma normal de Boyce-Codd se propuso como una forma más simple que la tercera, pero en realidad es más estricta porque cada relación en FNBC está en 3FN pero lo contrario no se cumple. Por ejemplo, considérese la siguiente relación, que está en 3FN pero no en FNBC.

En este ejemplo, que cumple la 3NF, hay una anomalía que se debería poder evitar, porque si no se vigila la dependencia funcional DF2 se podría añadir una tupla de manera que una persona fuese investigadora principal de dos proyectos.

Todas estas descomposiciones pierden la dependencia funcional DF1 porque las dependencias funcionales se refieren al contexto local de un esquema, no hacen referencia a esquemas externos.

Desnormalización para el rendimiento.

Utilizan la redundancia para mejorar el rendimiento para aplicaciones concretas. La penalización sufrida por no emplear un esquema normalizado es el trabajo extra de mantener consistentes los datos redundantes. En el esquema normalizado esto exige una reunión de cuenta con impositor. Una alternativa para calcular la reunión sobre la marcha es almacenar una relación que contenga todos los atributos de cuenta y de impositor. El proceso de tomar un esquema normalizado y hacerlo no normalizado se denomina desnormalización, y los diseñadores lo utilizan para ajustar el rendimiento de los sistemas para dar soporte a las operaciones críticas en el tiempo. Una alternativa mejor, soportada hoy en día por muchos sistemas de bases de datos, es emplear el esquema normalizado y, de manera adicional, almacenar la reunión en forma de vista materializada.

Normativa de denominación.

El objetivo es que los nombres que se elijan indiquen de forma lo más clara posible el significado del elemento al que se refiere el nombre. Cada empresa suele usar una normativa diferente y más o menos complicada.

Identificadores.

Los identificadores se construyen generalmente con letras y números. En muchos SGBD no se distinguen mayúsculas de minúsculas, pero su uso nos puede ayudar a hacer más legibles los identificadores. Separar cada palabra poniendo la primera letra de cada una en mayúsculas, como en NombreDelPaciente. Otra alternativa final, menos usada, es usar espacios en blanco para la separación, como en Nombre del paciente.

Tablas. Las tablas representan entidades y sus nombres deberían describir las entidades que representan. Por ejemplo, Pacientes sería un identificador que describe a una tabla que contiene información sobre las entidades Pacientes. Además se escribe en plural porque el tipo de entidad contiene un conjunto de entidades . Algunas tablas, sin embargo, no presentan entidades. Pueden representar relaciones entre entidades. Cuando no se pueda encontrar un identificador adecuado para una relación siempre se puede escribir un identificador con los dos nombres de las tablas, como PersonasTeléfonos.

Reglas básicas de denominación de tablas:

• Seleccionar nombres de tablas basados en los nombres posibles para las entidades involucradas. • Usar sustantivos para los nombres de las tablas. • Asegurarse de que los nombres tienen un sentido intuitivo en la cultura de quienes utilizan la base de datos. • Expresar las relaciones capturadas por las tablas mediante la vinculación de los nombres de las entidades vinculadas por la tabla. Las columnas representan elementos discretos de información sobra la entidad nombrada por la tabla.

Restricciones.

Después hay que utilizar el nombre de la tabla a la cual se aplica la restricción como segundo elemento del nombre. Una restricción de clave principal para la tabla Médicos se debería nombrar CP_Médicos. En el caso de claves externas, donde están involucradas dos tablas, hay que poner el nombre de la segunda tabla como tercer elemento para el nombre de la restricción. Cuando están involucradas dos tablas hay que hacer que el segundo elemento del nombre sea la tabla con la clave externa y que el tercer elemento sea la tabla donde reside la clave principal.

Controles.

Cada tipo de control se debería denominar con una indicación del tipo de control, anteponiendo a un nombre descriptor un prefijo que indique el tipo, como se propone en la siguiente tabla.

Variables.

Cada variable se debería denominar con una indicación del tipo de la variable, anteponiendo a un nombre descriptor un prefijo que indique el tipo, como se propone en la siguiente tabla.

Objetos de la base de datos.

Cada objeto de la base de datos se debería denominar con una indicación del tipo de objeto, anteponiendo a un nombre descriptor un prefijo que indique el tipo, como se propone en la siguiente tabla.