Antologia 4A JEMIMA

INSTITUTO TECNOLÓGICO SUPERIOR DE TEPEACA

INGENIERÍA EN SISTEMAS COMPUTACIONALES

FUNDAMENTOS DE BASES DE DATOS

CUARTO SEMESTRE GRUPO A

DOCENTE: ING. INÉS LEÓN FLOREZ

ANTOLOGÍA

UNIDAD 1. SISTEMAS GESTORES DE BASES DE DATOS, UNIDAD 2 DISEÑO DE

BASES DE DATOSY EL MODELO E-R

UNO

ALUMNO MATRÍCULA NOMBRE (S) CORREO ELECTRÓNICO11791033 CANO VAZQUEZ JEMIMA [email protected]

FECHA DE ENTREGA: 20 DE MARZO DE 2014 ( Debe ir subrayado)HORA: 10:00 hrs.

LUGAR: Salón de clases

“Creatividad Tecnológica Y Calidad Educativa, Pilares Para La Excelencia Humana”

mailto:[email protected]

ÍNDICE

UNIDAD 1. SISTEMAS GESTORES DE BASES DE DATOS................................4

1.1. Objetivo de las Bases de Datos..................................................................4

1.2. Áreas de Aplicación de los Sistemas de Bases de datos............................5

1.3. Modelos de datos........................................................................................6

1.4. Arquitectura del Sistema Gestor de Bases de datos...................................8

1.5. Niveles de abstracción..............................................................................10

1.6. Tipos de usuarios......................................................................................11

1.7. Tipos de lenguajes....................................................................................13

UNIDAD 2. DISEÑO DE BASES DE DATOS Y EL MODELO E-R.......................17

2.1 El Proceso de Diseño....................................................................................17

2.2 Modelo Entidad-Relación..............................................................................17

2.3 Restricciones.................................................................................................19

2.4 Diagramas E-R..............................................................................................21

2.5 Diseño con diagramas E-R...........................................................................23

2.6 Conjunto de entidades débiles......................................................................24

2.7 Modelo E-R extendido...................................................................................24

2.8 Otros aspectos del diseño de bases de datos..............................................25

2.9 La Notación E-R con UML............................................................................25

UNIDAD 3. MODELO RELACIONAL.....................................................................28

3.1 Estructura básica..........................................................................................28

3.2 Esquema de las bases de datos...................................................................31

3.3 Claves...........................................................................................................32

3.4 Lenguajes de consulta..................................................................................35

UNIDAD 4. DISEÑO DE LAS BASES DE DATOS RELACIONALES....................37

4.1 Características del diseño relacional............................................................37

4.2 Dominios atómicos y la primera forma normal..............................................40

4.3 Dependencias funcionales............................................................................44

4.4 Segunda forma normal..................................................................................45

4.5 Tercera forma normal....................................................................................48

INGENIERÍA DE SOFTWARE / AVANCE No. 1

4.6 Forma normal Boyce-Codd...........................................................................50

4.7 Algoritmos de descomposición.....................................................................52

4.8 Formas normales superiores........................................................................53

4.9 Integridad de las bases de datos..................................................................54

REFERENCIAS......................................................................................................57

“Creatividad Tecnológica Y Calidad Educativa, Pilares Para La Excelencia Humana” Página 3 de 58

ÍNDICE DE FIGURAS


UNIDAD 1. SISTEMAS GESTORES DE BASES DE DATOS.

1.1. Objetivo de las Bases de Datos.Un sistema gestor de bases de datos (SGBD) consiste en una colección de datos

interrelacionados y un conjunto de programas para acceder a dichos datos. La colección de

datos, normalmente denominada base de datos, contiene información relevante para una

empresa. El objetivo principal de un SGBD es proporcionar una forma de almacenar y

recuperar la información de una base de datos de manera que sea tanto práctica como

eficiente.

Los sistemas de bases de datos se diseñan para gestionar grandes cantidades de

información. La gestión de los datos implica tanto la definición de estructuras para almacenar

la información como la provisión de mecanismos para la manipulación de la información.

Además los sistemas de base de datos deben proporcionar la fiabilidad de la información

almacenada, a pesar de las caídas del sistema o los intentos de acceso sin autorización.

Una base de datos de puede definir como:

Una colección interrelacionada de datos, almacenados en un conjunto sin

redundancias innecesarias cuya finalidad es la de servir a una o más aplicaciones de

la manera más eficiente.

Conjunto de datos organizados con características afines entre sí, que identifican a un

ente en especial, cualquier colección de información interrelacionada, es una base de

datos.

Conjunto auto descriptivo de registros integrados; auto descriptivo ya que puede

contener información del usuario, descripción de la Base de Datos, que nos permiten

representar las relaciones entre los datos. En donde la información que se tiene

almacenada está disponible para todos los usuarios del sistema, en los que los datos

redundantes pueden eliminarse o al menos minimizarse.

Los componentes de una base de datos son:

Los datos: El componente fundamental de una base de datos son los datos que están

interrelacionados entre sí, formando un conjunto con un mínimo de redundancias.

El software: los datos, para que puedan ser utilizados por diferentes usuarios y diferentes

aplicaciones, deben estar estructurados y almacenados de forma independiente de las

aplicaciones. Para ello se utiliza un software o conjunto de programas que actúa de interfaz

entre los datos y las aplicaciones. A este software se le denomina Sistema de Gestión de



Base de Datos (SGBD). El SGBD crea y organiza la base de datos, y además atiende todas

las solicitudes de acceso hechas a la base de datos tanto por los usuarios como por las

aplicaciones.

Recurso Humano:

Informático: son los profesionales que definen y preparan la base de datos.

Usuarios: Son los que tienen acceso a la base de datos para ingresar o manipular la

información contenida en esta, dependiendo del nivel de usuario o control de

seguridad establecido.

1.2. Áreas de Aplicación de los Sistemas de Bases de datos.

Las bases de datos son ampliamente usadas. Las siguientes son algunas de sus aplicaciones

más representativas:

Banca: Para llevar el control de la información de los clientes, cuentas, prestamos y todas las

transacciones bancarias.

Líneas aéreas: Para llevar el control de todas las planificaciones de vuelos de una aerolínea y

las reservaciones hechas por los clientes. Las líneas aéreas fueron de las primeras en usar

las base de datos de forma distribuida geográficamente (las terminales situadas en todo el

mundo accedían al sistema de base de datos centralizado a través de las líneas telefónicas y

otras redes de datos).

Escuelas: Para llevar el control de los estudiantes, horarios, cursos, inscripciones y

calificaciones.

Transacciones de tarjetas de crédito: Para llevar el control de compras con tarjeta de crédito y

generación mensual de estados de cuenta de los usuarios.

Telecomunicaciones: Para guardar un registro de las llamadas realizadas, generación

mensual de factures, control del saldo de las tarjetas de prepago y almacenar información

sobre las redes de comunicaciones.

Finanzas: Para almacenar información sobre grandes empresas, ventas y compras de

documentos formales financieros, como bolsa y bonos.

Ventas: Para tener el control de la información de los clientes, productos y la información de

las ventas generadas de forma diaria o mensual según el control que se desee tener.



Producción: Para la gestión de la cadena de producción, seguimiento de la producción y

control de inventarios en almacén.

Recursos humanos: Para llevar el control de información sobre los empleados, salaries,

impuestos y con esto poder generar la nómina.

1.3. Modelos de datos.

Bajo la estructura de la base de datos se encuentra el modelo de datos: una colección de

herramientas conceptuales para describir los datos, las relaciones, la semántica y las

restricciones de consistencia.

Dentro del modelo de datos se encuentran:

Modelo Entidad-relación: El modelo de datos entidad-relación (E-R) está basado en una

percepción del mundo real que consta de una colección de objetos básicos, llamados

entidades, y de relaciones entre estos objetos. Una entidad es una cosa u objeto en el mundo

real que es distinguible de otros objetos. Las entidades se describen en una base de datos

mediante un conjunto de atributos. Una relación es una asociación entre varias entidades.

La estructura lógica general de una base de datos se puede expresar gráficamente mediante

un diagrama ER, que consta de los siguientes componentes:

Rectángulos, que representan conjuntos de entidades.

Elipses, que representan atributos.

Rombos, que representan relaciones entre conjuntos de entidades.

Líneas, que unen los atributos con los conjuntos de entidades y los conjuntos de

entidades con las relaciones.

Ejemplo de un diagrama entidad-relación (Figura 1.1).



Modelo Relacional.

En el modelo relacional se utiliza un grupo de tablas para representar los datos y las

relaciones entre ellos. Cada tabla está compuesta por varias columnas, y cada columna tiene

un nombre único.

El modelo relacional es un ejemplo de un modelo basado en registros. Los modelos basados

en registros se denominan así porque la base de datos se encuentra en registros de formato

fijo de varios tipos. Cada tabla contiene registros de un tipo particular. Cada tipo de registro

define un número fijo de campos, o atributos. Las columnas de la tabla corresponden a los

atributos del tipo de registro.

El modelo de datos relacional es el modelo de datos más ampliamente usado, y una amplia

mayoría de sistemas de bases de datos actuales se basan en el modelo relacional.

El modelo relacional se encuentra a un nivel de abstracción inferior al modelo de datos E-R

(Entidad-Relación). Los diseños de bases de datos a menudo se realizan en el modelo E-R, y

después se traducen al modelo relacional.

Modelo Orientado a Objetos. El modelo orientado a objetos se puede observar como una

extensión del modelo E-R con las nociones de encapsulación, métodos (funciones) e identidad

de objeto. El modelo de datos relacional orientado a objetos combina las características del

modelo de datos orientado a objetos y el modelo de datos relacional.

Los modelos de datos semiestructurados permiten la especificación de datos donde los

elementos de datos individuales del mismo tipo pueden tener diferentes conjuntos de

atributos.



Esto es diferente de los modelos de datos mencionados anteriormente, en los que cada

elemento de datos de un tipo particular debe tener el mismo conjunto de atributos. El lenguaje

de marcas extensible (XML, eXtensible Markup Language) se usa ampliamente para

representar datos semi-estructurados.

Históricamente, otros dos modelos de datos, el modelo de datos de red y el modelo de datos

jerárquico, precedieron al modelo de datos relacional. Estos modelos estuvieron ligados

fuertemente a la implementación subyacente y complicaban la tarea del modelado de datos.

Como resultado se usan muy poco actualmente, excepto en el código de bases de datos

antiguo que aún está en servicio en algunos lugares.

1.4. Arquitectura del Sistema Gestor de Bases de datos.

La mayoría de usuarios de un sistema de bases de datos no están situados actualmente junto

al sistema de bases de datos, sino que se conectan a él a través de una red.

Se puede diferenciar entonces entre las máquinas cliente, en donde trabajan los usuarios

remotos de la base de datos, y las máquinas servidor, en las que se ejecuta el sistema de

bases de datos.

Las aplicaciones de bases de datos se dividen usualmente en dos o tres partes, como se

ilustra en la Figura 1.2. En una arquitectura de dos capas, la aplicación se divide en un

componente que reside en la máquina cliente, que llama a la funcionalidad del sistema de

bases de datos en la máquina servidor mediante instrucciones del lenguaje de consultas. Los

estándares de interfaces de programas de aplicación como ODBC y JDBC se usan para la

interacción entre el cliente y el servidor.



En cambio, en una arquitectura de tres capas, la máquina cliente actúa simplemente como

frontal y no contiene ninguna llamada directa a la base de datos. En su lugar, el cliente se

comunica con un servidor de aplicaciones, usualmente mediante una interfaz de formularios.

El servidor de aplicaciones, a su vez, se comunica con el sistema de bases de datos para

acceder a los datos.

La lógica de negocio de la aplicación, que establece las acciones a realizar bajo determinadas

condiciones, se incorpora en el servidor de aplicaciones, en lugar de ser distribuida a múltiples

clientes. Las aplicaciones de tres capas son más apropiadas para grandes aplicaciones, y

para las aplicaciones que se ejecutan en World Wide Web.



1.5. Niveles de abstracción.

Para que el sistema sea útil debe recuperar los datos eficientemente. Esta preocupación ha

conducido al diseño de estructuras de datos complejas para la representación de los datos en

la base de datos. Como muchos usuarios de sistemas de bases de datos no están

familiarizados con computadores, los desarrolladores esconden la complejidad a los usuarios

a través de varios niveles de abstracción para simplificar la interacción de los usuarios con el

sistema, en la figura 1.3, se esquematizan los tres niveles de abstracción de base de datos. A

continuación se definen los principales niveles de abstracción:

Nivel físico. El nivel más bajo de abstracción describe cómo se almacenan realmente los

datos. En el nivel físico se describen en detalle las estructuras de datos complejas de bajo

nivel.

En el nivel físico, un registro cliente, cuenta o empleado se puede describir como un bloque de

posiciones almacenadas consecutivamente (por ejemplo, palabras o bytes). El compilador del

lenguaje esconde este nivel de detalle a los programadores. Análogamente, el sistema de

base de datos esconde muchos de los detalles de almacenamiento de nivel inferior a los

programadores de bases de datos. Los administradores de bases de datos pueden ser

conscientes de ciertos detalles de la organización física de los datos.

Nivel lógico. El siguiente nivel más alto de abstracción describe qué datos se almacenan en la

base de datos y qué relaciones existen entre esos datos. La base de datos completa se

describe así en términos de un número pequeño de estructuras relativamente simples. En el

nivel lógico cada registro de este tipo se describe mediante una definición de tipo y se define

la relación entre estos tipos de registros. Los programadores, cuando usan un lenguaje de

programación, trabajan en este nivel de abstracción. De forma similar, los administradores de

bases de datos trabajan habitualmente en este nivel de abstracción.

Nivel de vistas. El nivel más alto de abstracción describe sólo parte de la base de datos

completa. Muchos usuarios del sistema de base de datos no necesitan toda esta información.

En su lugar, tales usuarios necesitan acceder sólo a una parte de la base de datos. Para que

su interacción con el sistema se simplifique, se define la abstracción del nivel de vistas.

En el nivel de vistas, los usuarios de computadoras ven un conjunto de programas de

aplicación que esconden los detalles de los tipos de datos. Análogamente, en el nivel de vistas

se definen varias vistas de una base de datos y los usuarios de la misma ven única y

exclusivamente esas vistas. Además de esconder detalles del nivel lógico de la base de datos,



las vistas también proporcionan un mecanismo de seguridad para evitar que los usuarios

accedan a ciertas partes de la base de datos. Por ejemplo, los cajeros de un banco ven

únicamente la parte de la base de datos que tiene información de cuentas de clientes; no

pueden acceder a la información referente a los sueldos de los empleados.

1.6. Tipos de usuarios.

Un objetivo principal de un sistema de bases de datos es recuperar información y almacenar

nueva información en la base de datos. Las personas que trabajan con una base de datos se

pueden catalogar como usuarios de bases de datos o como administradores de bases de

datos, los cuales se describen a continuación.

Usuarios de bases de datos e interfaces de usuario.

Hay cuatro tipos diferentes de usuarios de un sistema de base de datos, diferenciados por la

forma en que ellos esperan interactuar con el sistema.

Usuarios normales.



Programadores de aplicaciones.

Los usuarios sofisticados.

Usuarios especializados.

Usuarios normales. Son usuarios no sofisticados que interactúan con el sistema mediante la

invocación de alguno de los programas de aplicación. Por ejemplo considere que un usuario

desea consultar su saldo a través de la web. Tal usuario únicamente puede acceder a un

formulario donde introduce su número de cuenta y clave de autentificación, en ese momento

un programa de aplicación en el servidor Web verifica su número de cuenta y clave, si son

válidos entonces recuera el saldo de la cuenta y muestra la información al usuario.

La interfaz de usuario para los usuarios normales en este caso es una interfaz de formularios,

donde el usuario solo puede llenar y realizar las acciones que se le indiquen en el formulario.

Los usuarios normales pueden también simplemente leer informes generados por la base de

datos.

Programadores de aplicaciones. Son profesionales informáticos que escriben programas de

aplicación. Los programadores de aplicación pueden elegir entre muchas herramientas para

desarrollar interfaces de usuario, las interfaces desarrolladas son las que deben tener

interacción con la base de datos.

Los usuarios sofisticados. Son los usuarios que interactúan con el sistema sin programas

escritos, se encargan de formar sus consultas en un lenguaje de consulta de base de datos.

Cada una de estas consultas se envía al procesador de consultas, cuya función es

transformar que se encuentran en un lenguaje de manipulación de datos (LMD) a

instrucciones que el gestor de almacenamiento entienda. Los analistas que envían las

consultas para explorar los datos en la base de datos entran en esta categoría.

Existen herramientas de procesamiento analítico que le permiten a los analistas simplificar su

trabajo, permitiendo una selección muy específica de registros, examinar datos con más

detalle, recopilación de datos que les ayudan a encontrar ciertas clases de patrones de datos

existentes dentro de la base de datos que pueden ser un auxiliar para la toma de decisiones

en una empresa.

Usuarios especializados. Son usuarios sofisticados que escriben aplicaciones de base de

datos especializadas que no son adecuadas en el marco de procesamiento de datos

tradicional, dentro de estas están los sistemas de diseño asistido por computadora, sistemas

de base de conocimientos y sistemas expertos, sistemas que almacenan los datos con tipos

de datos complejos (por ejemplo, datos gráficos y datos de audio) y sistemas de modelado del

entorno.



Administrador de la base de datos.

Una de las principales razones de usar SGBDs (Sistemas Manejadores de Base de Datos) es

tener un control centralizado tanto de los datos como de los programas que acceden a esos

datos. La persona que tiene este control central sobre el sistema se llama administrador de la

base de datos (ABD). Las funciones del ABD incluyen las siguientes:

Definición del esquema. El ABD crea el esquema original de la base de datos escribiendo un

conjunto de instrucciones de definición de datos en el LDD.

Definición de la estructura y del método de acceso.

Modificación del esquema y de la organización física. Los ABD realizan cambios en el

esquema y en la organización física para reflejar las necesidades cambiantes de la

organización, o para alterar la organización física para mejorar el rendimiento.

Concesión de autorización para el acceso a los datos. La concesión de diferentes tipos de

autorización permite al administrador de la base de datos determinar a qué partes de la base

de datos puede acceder cada usuario. La información de autorización se mantiene en una

estructura del sistema especial que el sistema de base de datos consulta cuando se intenta el

acceso a los datos en el sistema.

Mantenimiento rutinario. Algunos ejemplos de actividades rutinarias de mantenimiento del

administrador de la base de datos son:

Copia de seguridad periódica de la base de datos, bien sobre cinta o sobre servidores

remotos, para prevenir la pérdida de datos en caso de desastres como inundaciones.

Asegurarse de que haya suficiente espacio libre en disco para las operaciones

normales y aumentar el espacio en disco según sea necesario.

Supervisión de los trabajos que se ejecuten en la base de datos y asegurarse de que

el rendimiento no se degrada por tareas muy costosas iniciadas por algunos usuarios.

1.7. Tipos de lenguajes.

Tipos de lenguajes.

Un sistema de bases de datos proporciona un lenguaje de definición de datos para especificar

el esquema de la base de datos y un lenguaje de manipulación de datos para expresar las

consultas a la base de datos y las modificaciones.



Lenguaje de definición de datos.

Un esquema de base de datos se especifica mediante un conjunto de definiciones expresadas

mediante un lenguaje especial llamado lenguaje de definición de datos (LDD).

Por ejemplo, la siguiente instrucción en el lenguaje SQL define la tabla clientes:

create table clientes ( clave_cliente char(10), nombre char(20) )

La ejecución de la instrucción LDD (Lenguaje de Definición de Datos) anterior crea la tabla

clientes. Además, actualiza un conjunto especial de tablas denominado diccionario de datos o

directorio de datos.

Un diccionario de datos contiene metadatos, es decir, datos acerca de los datos. El esquema

de una tabla es un ejemplo de metadatos. Un sistema de base de datos consulta el diccionario

de datos antes de leer o modificar los datos reales.

Especificamos el almacenamiento y los métodos de acceso usados por el sistema de bases

de datos por un conjunto de instrucciones en un tipo especial de LDD denominado lenguaje de

almacenamiento y definición de datos. Estas instrucciones definen los detalles de

implementación de los esquemas de base de datos, que se ocultan usualmente a los usuarios.

Lenguaje de manipulación de datos

La manipulación de datos es:

La recuperación de información almacenada en la base de datos.

La inserción de información nueva en la base de datos.

El borrado de información de la base de datos.

La modificación de información almacenada en la base de datos.

Un lenguaje de manipulación de datos (LMD) es un lenguaje que permite a los usuarios

acceder o manipular los datos organizados mediante el modelo de datos apropiado. Hay dos

tipos básicamente:

LMDs procedimentales. Requieren que el usuario especifique qué datos se necesitan y

cómo obtener esos datos.



LMDs declarativos (también conocidos como LMDs no procedimentales). Requieren

que el usuario especifique qué datos se necesitan sin especificar cómo obtener esos

datos.

Los LMDs declarativos son más fáciles de aprender y usar que los LMDs procedimentales. Sin

embargo, como el usuario no especifica cómo conseguir los datos, el sistema de bases de

datos tiene que determinar un medio eficiente de acceder a los datos. El componente LMD del

lenguaje SQL es no procedimental. Una consulta es una instrucción de solicitud para

recuperar información. La parte de un LMD que implica recuperación de información se llama

lenguaje de consultas.

Aunque técnicamente sea incorrecto, en la práctica se usan los términos lenguaje de

consultas y lenguaje de manipulación de datos como sinónimos.

Esta consulta en el lenguaje SQL encuentra el nombre del cliente cuyo identificador de cliente

es 12345.

Esta consulta en el lenguaje SQL encuentra el nombre del cliente cuyo identificador de cliente

es 12345.

select clientes.nombre from clientes where clientes.clave_cliente= '12345'

Lo que está haciendo la consulta anterior es seleccionando (select) el nombre del cliente

(clientes.nombre) de (from) la tabla clientes, donde (where) la clave del cliente

(clientes.clave_cliente) sea igual a '12345'.

1.8 Tópicos selectos de bases de datos.

Las Bases de Datos (BD), si bien representan a una tecnología que ya cuenta con más de 40

años de historia, aún sigue desarrollándose y diversificándose. La razón de este desarrollo

continuo se debe principalmente a que en la actualidad las BD abordan problemas en los que

se integran tecnologías que tienen una amplia aceptación, entre ellas podemos mencionar la

tecnología de Orientación a Objetos, presente en las BD Orientadas a Objetos (BDOO), la

tecnología de Redes de Computadoras, presente en las BD Distribuidas (BDD), la tecnología

de Georeferenciación y Vectorización encontradas en las BD Espaciales utilizadas en los

Sistemas de Información Geográfica (SIGs), las tecnologías de acceso a información semi-

estructurada y la Web soportadas por las BD XML, las tecnologías para gestión de grandes



almacenes de datos reflejada en las BD Multidimencionales, etc. Dado que el universo en el

que se desenvuelven las BD es muy extenso, sería imposible tratar de cubrirlo en un sólo

curso, por lo que este curso se diseña con el fin de abordar algunos Tópicos Selectos, en

donde la selección y profundidad de cada tema se ajusta de acuerdo a criterios de relevancia,

actualidad y pertinencia emanados de necesidades que surgen de los trabajos de

investigación generados en el Cinvestav en el Área de BD .



UNIDAD 2. DISEÑO DE BASES DE DATOS Y EL MODELO E-R.

2.1 El Proceso de Diseño.

Los diseñadores entrevistan a los futuros usuarios de la base de datos para recoger y

documentar sus necesidades de información. En paralelo, conviene definir los requerimientos

funcionales que consisten en operaciones (transacciones) que se aplicarán a la base de

datos, e incluyen la obtención de datos y la actualización.

Diseño conceptual. Una vez recogidos todos los requerimientos, el siguiente paso es crear un

esquema conceptual para la base de datos mediante un modelo de datos conceptual de alto

nivel.

El esquema conceptual contiene una descripción detallada de los requerimientos de

información de los usuarios, y contiene descripciones de los tipos de datos, relaciones entre

ellos y restricciones.

Diseño lógico de la base de datos (transformación de modelo de datos) El siguiente paso en el

proceso de diseño consiste en implementar de hecho la base de datos con un SGBD (Sistema

Manejador de Base de Datos) comercial, transformando el modelo conceptual al modelo de

datos empleados por el SGBD (entidad-relación, jerárquico, red o relacional).

Diseño físico de la base de datos En este paso se especifican las estructuras de

almacenamiento internas y la organización de los archivos de la base de datos.

2.2 Modelo Entidad-Relación.

El modelo de datos entidad-relación (E-R) está basado en una percepción del mundo real

consistente en objetos básicos llamados entidades y de relaciones entre estos objetos.

Se desarrolló para facilitar el diseño de bases de datos permitiendo la especificación de un

esquema de la empresa que representa la estructura lógica completa de una base de datos.



El modelo E-R (Entidad-Relación) además de entidades y relaciones representan las uniones

que los contenidos de la base de datos deben cumplir. Una unión es la correspondencia de

cardinalidades, que expresan el número de entidades con las que otra entidad se puede

asociar a través de un conjunto de relaciones.

Conceptos básicos: Existen tres conceptos fundamentales que se emplean en el modelo de

datos E-R (Entidad-Relación): conjunto de entidades, conjunto de relaciones y atributos, las

cuales se definen a continuación.

Entidad: Se puede definir cono Entidad a cualquier objeto, real o abstracto, que existe en un

contexto determinado o puede llegar a existir y del cual deseamos guardar información. Una

entidad tiene propiedades y valores que identifican a un sujeto u objeto el cual existe y es

distinguible de otros objetos, se representan por un conjunto de atributos, ejemplo entidad

cliente: rfc, nombre, dirección, teléfono.

Un conjunto de entidades es un conjunto de entidades del mismo tipo que comparten las

mismas propiedades, o atributos.

Atributos: Los Atributos son características o propiedades asociadas a la entidad que toman

valor en una instancia particular. Ejemplo: nombre, cédula, teléfono. Cada entidad tiene un

valor para cada uno de sus atributos.

Dominio del atributo: Para cada atributo hay un conjunto de valores permitidos, llamados el

dominio, o el conjunto de valores, de ese atributo.

Un atributo, como se usa en el modelo E-R, se puede caracterizar por los siguientes tipos de

atributo:

Atributos simples: Un atributo simple es aquel que no se puede subdividir, por ejemplo

la edad y el sexo de una persona.

Atributos compuestos: Un atributo compuesto, es un atributo que puede ser

subdividido en otros atributos adicionales, por ejemplo la dirección de una persona,

puede subdividirse en calle, número, código postal, etc.

Atributos monovalorados y multivalorados.

Atributos derivados.

Llave o clave de la relación: Es el identificador único de cada tupla.

Clave primaria: clave candidata que el diseñador elige de la base de datos como el medio

principal de identificar entidades dentro de un conjunto de entidades.

Clave compuesta: Una clave compuesta de más de un atributo.



Clave candidata: Cualquier conjunto de atributos que puede ser elegido como clave de una

relación.

Clave externa: Un conjunto de atributos o un atributo, en una relación que constituyen una

clave en alguna otra relación, usada para establecer enlaces lógicos entre relaciones.

Tupla: Conjunto de atributos que representan a una unidad. Valor nulo: El valor dado a un

atributo en una tupla si el atributo es inaplicable o su valor es desconocido.

Cardinalidad: Numero especifico de ocurrencias de una entidad, asociadas con una ocurrencia

de la entidad relacionada, esto es el número máximo de instancias de un conjunto de objetos

que puede estar relacionado con una sola instancia de otro conjunto de objetos.

Relación: Una relación es una asociación entre entidades, se denomina de igual modo a una

tabla que se genera a partir de la relación o asociación de dos o más tablas o entidades

existentes.

2.3 Restricciones.

Un esquema de desarrollo E-R puede definir ciertas restricciones a las que los contenidos de

la base de datos se deben adaptar. En este apartado se examina la correspondencia de

cardinalidades y las restricciones de participación, que son dos de los tipos más importantes

de restricciones.

La correspondencia de cardinalidades, o razón de cardinalidad, expresa el número de

entidades a las que otra entidad puede estar asociada vía un conjunto de relaciones.

Reglas de cardinalidad:

Cardinalidad de uno a uno: Una carnidalidad de la interrelación que es 1 en ambas

direcciones. Cuando un registro de una tabla sólo puede estar relacionado con un único

registro de la otra tabla y viceversa. En este caso la clave foránea se ubica en alguna de las 2

tablas.

Cardinalidad de uno a muchos: Cuando un registro de una tabla (tabla secundaria) sólo puede

estar relacionado con un único registro de la otra tabla (tabla principal) y un registro de la tabla

principal puede tener más de un registro relacionado en la tabla secundaria. En este caso la

clave foránea se ubica en la tabla secundaria.

Cardinalidad de muchos a muchos: Cuando un registro de una tabla puede estar relacionado

con más de un registro de la otra tabla y viceversa. En este caso las dos tablas no pueden



estar relacionadas directamente, se tiene que añadir una tabla entre las dos (Tabla débil o de

vinculación) que incluya los pares de valores relacionados entre sí.

El nombre de tabla débil deviene de que con sus atributos propios no se puede encontrar la

clave, por estar asociada a otra entidad. La clave de esta tabla se conforma por la unión de los

campos claves de las tablas que relaciona.

Reglas que determinan las interrelaciones (cardinalidad).

Regla 1. Si dos tablas tienen una interrelación de uno a uno (1 a 1), entonces el campo clave

de una de las tablas debe aparecer en la otra tabla.

Regla 2. Si dos tablas tienen una interrelación de uno a muchos (1 a *), entonces el campo

clave de la tabla del (1) debe aparecer en la tabla del muchos (*).

Regla 3. Si dos tablas tienen una interrelación de muchos a muchos (* a *), entonces debe

crearse una tabla que tenga los campos claves de las dos tablas.

Ejemplos:

Las relaciones entre entidades se generan en dos direcciones, 1. Si se quiere definir la

relación entre un empleado y un departamento se especifica de la siguiente manera:

Un empleado pertenece a un departamento.

En un departamento están asignados muchos empleados.

Esta relación es de tipo 1:M

2. Para una interrelación entre un supervisor y un departamento, la cardinalidad es de una a

una, en donde el 1 es representado por 1.

Un supervisor, supervisa un departamento.

Un departamento es supervisado por una persona.

En este caso la relación es de uno a uno.



3. Para una interrelación entre un supervisor y empleados, la cardinalidad es de una a mucho,

en donde él muchos puede ser representado por un (*), o la letra m.

Un supervisor supervisa a muchos empleados.

Un empleado es supervisado por un supervisor.

En este caso la relación es de uno a muchos.

4. En una relación entre alumnos y materias cursadas, la cardinalidad es de muchos a

muchos.

Un alumno cursa muchas materias.

Una materia la cursan muchos alumnos.

En este caso es una interrelación de muchos a muchos.

Co

mo en este ejemplo se tiene una relación de muchos a muchos, se genera una tercera entidad

débil (Cursa), que se forma con las llaves primarias de la entidad Alumno y Materias.

2.4 Diagramas E-R.

La estructura lógica general de una base de datos se puede expresar gráficamente mediante

un diagrama E-R. Los diagramas son simples y claros, cualidades que pueden ser

responsables del amplio uso del modelo E-R. Tal diagrama consta de los siguientes

componentes principales:

Rectángulos, que representan conjuntos de entidades. Elipses, que representan

atributos. Rombos, que representan relaciones. Líneas, que unen atributos a conjuntos de

entidades y conjuntos de entidades a conjuntos de relaciones. Elipses dobles, que

representan atributos multivalorados. Elipses discontinuas, que denotan atributos

derivados. Líneas dobles, que indican participación total de una entidad en un conjunto de

relaciones. Rectángulos dobles, que representan conjuntos de entidades débiles.



Ejemplo de un diagrama Entidad-Relación:

En este modelo se representa a las entidades cliente y cuenta, además de una tabla generada

por la relación denominada tiene.

La tabla cliente contiene los atributos: Id_cliente, Nombre, Dirección, Teléfono. La tabla cuenta

contiene los atributos: Numero_cuenta, Saldo.



2.5 Diseño con diagramas E-R.

El modelo de datos E-R da una flexibilidad sustancial en el diseño de un esquema de bases

de datos para modelar una empresa dada. En este apartado se considera cómo un diseñador

de bases de datos puede seleccionar entre el amplio rango de alternativas. Entre las

decisiones que se toman están las siguientes:

Si se usa un atributo o un conjunto de entidades para representa un objeto.

Si un concepto del mundo real se expresa más exactamente mediante un conjunto de

entidades o mediante un conjunto de relaciones.

Si se usa una relación ternaria o un par de relaciones binaras.

Si se usa un conjunto de entidades fuertes o débiles; un conjunto de entidades fuertes

y sus conjuntos de entidades débiles dependientes se pueden considerar como un

objeto en la base de datos, debido a que la existencia de las entidades débiles

depende de la entidad fuerte.

Un modelo de datos de alto nivel sirve al diseñador de la base de datos para proporcionar un

marco conceptual en el que especificar de forma sistemática los requisitos de datos de los

usuarios de la base de datos que existen, y cómo se estructurará la base de datos para

completar estos requisitos. La fase inicial del diseño de bases de datos, por tanto, es

caracterizar completamente las necesidades de datos esperadas por los usuarios de la base

de datos. El resultado de esta fase es una especificación de requisitos del usuario. Esta

estructura general se puede expresar gráficamente mediante un diagrama E-R.

A continuación, el diseñador elige un modelo de datos y, aplicando los conceptos del modelo

de datos elegido, traduce estos requisitos a un esquema conceptual de la base de datos. El

esquema desarrollado en esta fase de diseño conceptual proporciona una visión detallada del

desarrollo. Debido a que sólo se ha estudiado el modelo E-R hasta ahora, se usará éste para

desarrollar el esquema conceptual. En términos del modelo E-R, el esquema especifica todos

los conjuntos de entidades, conjuntos de relaciones, atributos y restricciones de

correspondencia.

El diseñador revisa el esquema para confirmar que todos los requisitos de datos se satisfacen

realmente y no hay conflictos entre sí. También se examina el diseño para eliminar

características redundantes. Lo importante en este punto es describir los datos y las

relaciones, más que especificar detalles del almacenamiento físico.



Un esquema conceptual completamente desarrollado indicará también los requisitos

funcionales de la empresa. En una especificación de requisitos funcionales los usuarios

describen los tipos de operaciones (o transacciones) que se realizarán sobre los datos.

Algunos ejemplos de operaciones son la modificación o actualización de datos, la búsqueda y

recuperación de datos específicos y el borrado de datos. En esta fase de diseño conceptual se

puede hacer una revisión del esquema para encontrar los requisitos funcionales.

El proceso de trasladar un modelo abstracto de datos a la implementación de la base de datos

consta de dos fases de diseño finales. En la fase de diseño lógico, el diseñador traduce el

esquema conceptual de alto nivel al modelo de datos de la implementación del sistema de

base de datos que se usará. El diseñador usa el esquema resultante específico a la base de

datos en la siguiente fase de diseño físico, en la que se especifican las características físicas

de la base de datos.

2.6 Conjunto de entidades débiles.

Las entidades que no tienen atributos llave se conocen como entidades débiles. Las entidades

de este tipo se identifican relacionándolas con otras entidades en combinación con algunos de

sus atributos. Esa otra entidad se denomina entidad fuerte o propietaria.

Una entidad débil siempre tiene una dependencia de existencia (restricción de participación

total) con respecto a la entidad fuerte.

Como ya se mencionaba anteriormente cuando se tiene una relación de muchos a muchos

entre dos entidades se genera una tercera entidad denominada "débil", una entidad débil no

tiene llave primaria y sus atributos principales son las llaves primarias de las entidades que se

están relacionando.

2.7 Modelo E-R extendido.

Aunque los conceptos básicos de E-R pueden modelar la mayoría de las características de las

bases de datos, algunos aspectos de una base de datos pueden ser más adecuadamente

expresados mediante ciertas extensiones del modelo E-R básico. A continuación se definen



las características E-R extendidas de especialización, generalización, conjuntos de entidades

de nivel más alto y más bajo, herencia de atributos y agregación.

La especialización y la generalización definen una relación de contenido entre un conjunto de

entidades de nivel más alto y uno o más conjuntos de entidades de nivel más bajo. La

especialización es el resultado de tomar un subconjunto de un conjunto de entidades de nivel

más alto para formar un conjunto de entidades de nivel más bajo. La generalización es el

resultado de tomar la unión de dos o más conjuntos disjuntos de entidades (de nivel más bajo)

para producir un conjunto de entidades de nivel más alto. Los atributos de los conjuntos de

entidades de nivel más alto los heredan los conjuntos de entidades de nivel más bajo.

La agregación es una abstracción en la que los conjuntos de relaciones (junto con sus

conjuntos de entidades asociados) se tratan como conjuntos de entidades de nivel más alto, y

pueden participar en las relaciones.

2.8 Otros aspectos del diseño de bases de datos.

Al momento de diseñar un modelo de base de datos se deben considerar los siguientes

aspectos:

Obtener los Requisitos de datos.

Designación de los conjuntos de entidades

Designación de los conjuntos de relaciones

Realizar el diseño del Diagrama E-R

2.9 La Notación E-R con UML.

Los diagramas entidad-relación ayudan a modelar el componente de representación de datos

de un sistema software. La representación de datos, sin embargo, sólo forma parte de un

diseño completo de un sistema.

Otros componentes son modelos de interacción del usuario con el sistema, especificación de

módulos funcionales del sistema y su interacción, etc. El lenguaje de modelado unificado

(UML, Unified Modeling Language) es un estándar propuesto para la creación de



especificaciones de varios componentes de un sistema software. Algunas de las partes de

UML son:

Diagrama de clase. Un diagrama de clase es similar a un diagrama E-R.

Diagrama de caso de uso. Los diagramas de caso de uso muestran la interacción

entre los usuarios y el sistema, en particular los pasos de las tareas que realiza el

usuario.

Diagrama de actividad. Los diagramas de actividad describen el flujo de tareas entre

varios componentes de un sistema.

Diagrama de implementación. Los diagramas de implementación muestran los

componentes del sistema y sus interconexiones tanto en el nivel del componente

software como el hardware.

Un tópico es una idea o un tema en específico, en este caso bases de datos, así que

resumiremos los tópicos más importantes, o selectos de bases de datos.

Una base de datos es una biblioteca donde a de mantener listas de los libros que posee, de

los usuarios que tiene de sus productos, ventas y empleados.

A este tipo de información se le llama datos.

Un gestor de base de datos es un programa que permite introducir y almacenar datos,

ordenarlos y manipularlos. Organizarlos de manera significativa para que se pueda obtener

información no visible como totales, tendencias o relaciones de otro tipo.

Debe permitir:

-Introducir datos

-Almacenar datos

-Recuperar datos y trabajar con ellos

Tabla o fichero, registro y campo

Un programa de base de datos almacena la información que introducimos en forma de tablas

como las que podemos ver, por ejemplo, en una lista telefónica.

Registro: es el concepto básico en el almacenamiento de datos. El registro agrupa la

información asociada a un elemento de un conjunto y está compuesto por campos.“Creatividad Tecnológica Y Calidad Educativa, Pilares Para La Excelencia Humana” Página 27 de 58


Tabla: conjunto de registros homogéneos con la misma estructura.

Tipos de base de datos: planas y relacionales

Para hacer una base de datos que cumpla las funciones de listín telefónico necesitamos una

sola tabla, pero puede haber casos en los que necesitemos más de una.

A esta forma de organizar la base de datos mediante distintas tablas relacionadas por campos

comunes se le llama base de datos relacional.

No todos los programas de gestión de base de datos tienen esta capacidad de manejar bases

de datos relacionales, por eso, antes de elegir uno deberemos considerar si necesitamos o no

esta capacidad.

Esta base de datos relacional estará formada por tablas. Con la característica de que las

mismas se relacionan entre sí mediante uno o más campos. Se puede decir que cada objeto

de la realidad será una tabla en nuestra base de datos y que hay que buscar la manera de

reflejar las relaciones antes mencionadas.

Para este tipo de bases de datos con múltiples usuarios aparecieron las llamadas bases de

datos de red. Estas están situadas en un único ordenador –llamado servidor (generalmente

ordenadores de gran potencia) y se puede acceder a ellas desde terminales u ordenadores

con un programa que permita el acceso a ella –los llamados clientes–. Los Gestores de bases

de datos de este tipo permiten que varios usuarios hagan operaciones sobre ella al mismo

tiempo: uno puede hacer una consulta al mismo tiempo que otro, situado en un lugar diferente,

está introduciendo datos en la base.

Utilidad de una base de datos: Las tres cosas básicas que debe permitir un gestor de base de

datos son: introducir datos, almacenarlos y recuperarlos.

Al mismo tiempo permiten otra serie de funciones que hacen de ellos herramientas

incomparablemente superiores a los métodos tradicionales de almacenamiento de datos:

archivadores, carpetas, etc.

Cualquier gestor debe permitir: ordenar los datos, realizar búsquedas, mostrar distintas vistas

de los datos, realizar cálculos sobre ellos, resumirlos, generar informes a partir de ellos,

importarlos y exportarlos.



UNIDAD 3. MODELO RELACIONAL

El modelo relacional se ha establecido actualmente como el principal modelo de datos para

las aplicaciones de procesamiento de datos. Ha conseguido la posición principal debido a su

simplicidad, que facilita el trabajo del programador en comparación con otros modelos.

Una base de datos relacional consiste en un conjunto de tablas, a cada una de las cuales se

le asigna un nombre exclusivo. Cada tabla tiene una estructura parecida a la presentada en la

unidad 2, donde se representaron las bases de datos E-R mediante tablas.

3.1 Estructura básica.

Una tabla en el modelo relacional viene a ser como una de las listas descritas anteriormente.

Una tabla o relación es una matriz rectangular que almacena líneas con una estructura

concreta:

La primera línea de una tabla, es una cabecera que indica el nombre de cada

columna. O sea, cada columna tiene asignado un nombre único.

Cada línea (excepto la primera) recibe el nombre de tupla, y almacena ítemes

concretos para cada columna.

Todas las filas deben ser diferentes entre sí.

El orden de las filas y de las columnas carece de importancia a efectos del S.G.B.D.

Este hecho es el que verdaderamente diferencia las tablas relacionales del concepto

matemático de relación, en el que el orden de las columnas es fundamental.

Dominio de Valores. Los dominios a que puede pertenecer un atributo, suelen depender de los

que proporcione el S.G.B.D. que empleemos. Suelen ser comunes dominios como: Texto,

Número entero, Número decimal, Fecha, Hora, Sí/No, etc.

Por otro lado, un dominio como pueda ser Número entero, es un dominio cuyo conjunto de

valores es infinito, y dado que trabajamos con ordenadores, es imprescindible poner un límite

que permita almacenar un valor concreto debido a las limitaciones de memoria, y sobre todo al

hecho de que toda tupla debe poseer el mismo tamaño.



Se trata de un modelo bastante potente y a la vez bastante simple, que nos representas

problemas. El elemento principal de este modelo es la relación. Por lo que podemos decir que

una base de datos relacional está compuesta por un conjunto de relaciones.

Relación: La relación se representa mediante una tabla, esta tabla representa a lo que en el

modelo entidad-relación llamábamos entidad. Esta tabla contiene los atributos (columnas) y

las tuplas (filas).

Atributo: se trata de cada una de las columnas de la tabla. Vienen definidas por un nombre y

pueden contener un conjunto de valores.

Tupla: se trata de cada una de las filas de la tabla. Es importante señalar que no se pueden

tener tuplas duplicadas en una tabla.

Dominios: El dominio dentro de la estructura del modelo relacional es el conjunto de valores

que puede tomar un atributo. Existen dos tipos de dominios:

Dominios generales: son aquellos que están comprendidos entre un máximo y un mínimo.

Dominios restringidos: son los que pertenecen a un conjunto de valores específicos.

Claves: Cada tupla de una tabla tiene que estar asociada a una clave única que permita

identificarla. Una clave puede estar compuesta por uno o más atributos.

Una clave tiene que ser única dentro de su tabla y no se puede descartar ningún atributo de la

misma para identificar una fila.

Existen dos tipos de claves:

Clave prmaria (Primary Key): es el valor o conjunto de valores que identifican una fila dentro

de una tabla. Nunca puede ser NULL. Un ejemplo claro de clave primaria seria el DNI, que es

único para cada persona y no puede ser NULL.

Clave ajena (Foreign Key): es el valor o valores de una tabla que corresponde con el valor de

una clave primaria en otra tabla. Esta clave es la que representa las relaciones entre las

tablas.



Vistas: Se trata de una tabla ficticia la cual muestra atributos de otras tablas relacionadas. De

esta forma obtenemos los datos que nos interesan de una o varias tablas. Es importante

señalar que no se pueden realizar operaciones sobre vistas.

La relación es el elemento básico del modelo relacional, y se puede representar como una

tabla.

En ella podemos distinguir su nombre, un conjunto de columnas, denominadas atributos, que

representan propiedades de la tabla y que también están caracterizadas por su nombre, y un

conjunto de filas llamadas tuplas, que contienen los valores que toma cada uno de los

atributos para cada elemento de la relación.

Grado: número de atributos

Cardinalidad: número de tuplas

En una tabla se puede distinguir una cabecera que define la estructura de la tabla; es decir,

sus atributos con los dominios subyacentes, y un cuerpo que está formado por un conjunto de

tuplas que varían en el tiempo.

Esta representación de la relación como una tabla ha sido el origen de que los productos

relacionales y los usuarios utilicen habitualmente el nombre de tabla (en principio ajeno a la

teoría relacional) para denominar las relaciones y, como consecuencia de ello, se llame filas a

las tuplas y columnas a los atributos; si bien, la terminología es irrelevante y un producto no es

más o menos relacional por utilizar una u otra terminología.



3.2 Esquema de las bases de datos.

Un esquema de bases de datos, junto con las dependencias de clave primaria y externa, se

puede mostrar gráficamente mediante diagramas de esquema.

Ejemplo de un esquema de base de datos:

El esquema de una base de datos (en inglés, Database Schema) describe la estructura de

una Base de datos, en un lenguaje formal soportado por un Sistema administrador de Base de

datos (DBMS). En una Base de datos Relacional, el Esquema define sus tablas, sus campos

en cada tabla y las relaciones entre cada campo y cada tabla.



El esquema es generalmente almacenado en un Diccionario de Datos. Aunque generalmente

el esquema es definido en un lenguaje de Base de datos, el término se usa a menudo para

referirse a una representación gráfica de la estructura de base de datos.

El esquema de una base de datos (en inglés, Database Schema) describe la estructura de

una Base de datos, en un lenguaje formal soportado por un Sistema administrador de Base de

datos (DBMS). En una Base de datos Relacional, el Esquema define sus tablas, sus campos

en cada tabla y las relaciones entre cada campo y cada tabla.

El esquema es generalmente almacenado en un Diccionario de Datos. Aunque generalmente

el esquema es definido en un lenguaje de Base de datos, el término se usa a menudo para

referirse a una representación gráfica de la estructura de base de datos (Diseño de lógico de

la base de datos).

3.3 Claves. Una clave es un atributo o conjunto de atributos cuyo valor es único y diferente para

cada tupla.

Tenemos dos claves potenciales, también llamadas claves candidatas.

De entre todas las claves candidatas, el administrador, cuando define la tabla, debe

decidir cuál de ellas va a ser la clave principal o clave primaria, mientras que el resto

de las claves pasan a denominarse claves alternativas o claves alternas.

Si el esquema de una base de datos relacional se basa en las tablas derivadas de un

esquema E-R es posible determinar la clave primaria del esquema de una relación a partir de

las claves primarias de los conjuntos de entidades o de relaciones de los que se deriva el

esquema:



Conjunto de entidades fuertes. La clave primaria del conjunto de entidades se convierte en la

clave primaria de la relación.

Conjunto de entidades débiles. La tabla y, por tanto, la relación correspondientes a un

conjunto de entidades débiles incluyen:

Los atributos del conjunto de entidades débiles.

La clave primaria del conjunto de entidades fuertes del que depende el conjunto de

entidades débiles.

La clave primaria de la relación consiste en la unión de la clave primaria del conjunto

de entidades fuertes y el discriminante del conjunto de entidades débil.

Conjunto de relaciones. La unión de las claves primarias de los conjuntos de entidades

relacionados se transforma en una superclave de la relación. Si la relación es de varios a

varios, esta superclave es también la clave primaria.

En cualquier base de datos los registros incluidos en sus diferentes tablas deben estar

perfectamente identificados y de esto se encargan las claves o llaves. Trasladando este

concepto a la vida real, cada ciudadano tiene un número de CURP, puede haber dos

personas con igual nombre e incluso apellidos iguales, pero ambos se diferenciarán por su

CURP, que es único en "teoría".

Cada tabla debe contener al menos un campo que permita identificar unívocamente cada

registro. Este campo puede ser real, como el propio CURP de una persona. O puede ser un

valor que nos inventemos para conseguir el mismo fin, como un número que asignemos

automáticamente a cada registro, asegurándonos (realmente lo hará Base) de que no se

repita. Otra opción es utilizar una combinación de campos para identificar los registros de la

tabla. Por ejemplo podríamos definir la combinación de Nombre y Apellidos de nuestra tabla

para este fin. Sin embargo, existe la probabilidad de que haya alumnos con igual nombre y

apellidos, por lo que no sería una clave del todo válida.

Clave.

Es un conjunto de atributos que identifican de forma unívoca una entidad.



Superclave.

Una superclave es un conjunto de uno o más atributos que, tomados colectivamente, permiten

identificar de forma única una entidad en el conjunto de entidades.

Clave Principal.

Una clave principal es un campo (o conjunto de campos) que identifica inequívocamente un

registro. Es decir, es un campo que no admite valores duplicados en los registros.

Una clave principal contiene la información que necesita el gestor de bases de datos para

modificar el registro, y permite además implementar la integridad referencial.

Las claves principales nos van a permitir:

Claves externas.

Una clave externa es un campo (o conjunto de campos), cuyos posibles valores están

limitados a los que se hayan definido en otra tabla como clave principal.

Claves Candidatas.

Una característica que debemos buscar siempre en las claves es que contenganel número

mínimo de atributos, siempre que mantengan su función. Diremos que una clave es mínima

cuando si se elimina cualquiera de los atributos que la componen, deja de ser clave. Si en una

entidad existe más de una de estas claves mínimas, cada una de ellas es una clave

candidata.

Clave candidata: es cada una de las claves mínimas existente en un conjunto de entidades

Claves de interrelaciones.



Tengamos en cuenta que para definir una interrelación usaremos las claves primarias de las

entidades interrelacionadas. De este modo, el identificador de una interrelación es el conjunto

de las claves primarias de cada una de las entidades interrelacionadas.

Clave Alternativa.

Una clave alternativa es aquella clave candidata que no ha sido seleccionada como clave

primaria, pero que también puede identificar de forma única a una fila dentro de una tabla.

3.4 Lenguajes de consulta.

Un lenguaje de consulta es un lenguaje en el que un usuario solicita información de la base de

datos. Estos lenguajes suelen ser de un nivel superior que el de los lenguajes de

programación habituales. Los lenguajes de consulta pueden clasificarse como

procedimentales o no procedimentales. En los lenguajes procedimentales el usuario instruye

al sistema para que lleve a cabo una serie de operaciones en la base de datos para calcular el

resultado deseado. En los lenguajes no procedimentales el usuario describe la información

deseada sin dar un procedimiento concreto para obtener esa información.

La mayor parte de los sistemas comerciales de bases de datos relacionales ofrecen un

lenguaje de consulta que incluye elementos de los enfoques procedimental y no

procedimental.

Un lenguaje de consulta es un lenguaje informático usado para hacer consultas en bases de

datos y sistemas de información.

Los lenguajes de consulta pueden ser clasificados de acuerdo a si son lenguajes de consulta

de bases de datos o lenguajes de consulta de recuperación de información. Algunos ejemplos

son:

.QL es un lenguaje de consulta propietario orientado a objetos para consultar

bases de datos relacionales;1

CODASYL;

D es un lenguaje de consulta para sistemas de administración de bases de

datos verdaderamente relacionales (truly relational database management systems -

TRDBMS);2

DMX es un lenguaje para modelos de minería de datos;



Datalog es un lenguaje de consulta para bases de datos deductivas;

ERROL es un lenguaje de consulta sobre el modelo entidad-relación (ERM),

especialmente diseñado para bases de datos relacionales;

Gellish English es un lenguaje que puede ser usado para consultas en bases de

datos Gellish English,3 para diálogos (pedidos y respuestas) como también para

modelado de información y modelado de conocimiento;

ISBL es un lenguaje de consulta para PRTV, uno de los más recientes sistemas

de administración de bases de datos;

MQL es un lenguaje de consulta de quimioinformática para búsqueda de

subestructuras permitiendo propiedades nominales y numéricas;

MDX es un lenguaje de consulta para bases de datos OLAP;

OQL es un lenguaje de consulta de objetos;

OPath, pensado para el uso consultando almacenes WinFS;

QUEL es un lenguaje de acceso a bases de datos relacionales, muy similar a

SQL;

SMARTS es el estándar de quimioinformática para búsqueda de

subestructuras;5

SPARQL es un lenguaje de consulta para grafos RDF;

SQL es un lenguaje de consulta muy reconocido para bases de datos

relacionales;

SuprTool es un lenguaje de consulta propietario para SuprTool,6 un programa

de acceso a bases de datos para obtener datos en Image/SQL (TurboIMAGE) y bases

de datos Oracle;

TMQL Topo Magic Queeen Lion es un lenguaje de consulta para Topic Maps;

XQuery es un lenguaje de consulta para fuentes de datos XML;

UNIDAD 4. DISEÑO DE LAS BASES DE DATOS RELACIONALES



El modelo relacional para la gestión de una base de datos es un modelo de datos basado en

la lógica de predicados y en la teoría de conjuntos. Es el modelo más utilizado en la actualidad

para modelar problemas reales y administrar datos dinámicamente.

Tras ser postuladas sus bases en 1970 por Edgar Frank Codd, de los laboratorios IBM en San

José (California), no tardó en consolidarse como un nuevo paradigma en los modelos de base

de datos.

Su idea fundamental es el uso de «relaciones». Estas relaciones podrían considerarse en

forma lógica como conjuntos de datos llamados «tuplas». Pese a que ésta es la teoría de las

bases de datos relacionales creadas por Edgar Frank Codd, la mayoría de las veces se

conceptualiza de una manera más fácil de imaginar, esto es, pensando en cada relación como

si fuese una tabla que está compuesta por registros (cada fila de la tabla sería un registro o

tupla), y columnas (también llamadas campos).

4.1 Características del diseño relacional.

El modelo relacional, está basado en las relaciones lógicas entre los datos, este modelo

organiza y representa a los datos en forma de tablas de dos dimensiones, consistente en filas

y columnas de datos.

El concepto de base de datos relacional fue escrito por primera vez por el Dr. Codd en 1970 el

cual publicó un artículo en que aplicaba los conceptos de una rama de las matemáticas

llamada algebra relacional, a los problemas de almacenar enormes cantidades de datos. Este

artículo dio inicio a un movimiento en la comunidad de las bases de datos que en muy poco

tiempo condujo a la definición del modelo de base de datos relacionales.

El modelo relacional surge como un intento de simplificar la estructura de las bases de datos,

eliminando estructuras padre/hijo del modelo jerárquico de la base de datos y en su lugar

representar todos los datos en la base de datos como tablas conformada a su vez por

renglones y columnas con valores de datos.

Este modelo, es un modelo simple, poderoso y formal de representar la realidad, que facilita la

construcción de consultas de usuario.



El objetivo del diseño de las bases de datos relacionales es la generación de un conjunto de

esquemas relacionales que nos permita almacenar la información sin redundancias

innecesarias, pero que también nos permita recuperar fácilmente esa información.

Normalización:

La normalización de bases de datos relacionales toma un esquema relacional y le aplica un

conjunto de técnicas para producir un nuevo esquema que representa la misma información

pero contiene menos redundancias y evita posibles anomalías en las inserciones,

actualizaciones y borrados. La técnica de normalización es semejante a lo que comúnmente

se dice de que un párrafo debe tener un solo tema, si un párrafo tiene más de un tema, debe

dividirse en tantos párrafos como temas se consideren. La lógica que se aplica a la

normalización es cada afinidad normalizada tiene un solo tema, si tiene dos o más, deberá

fragmentarse en afinidades, cada una de las cuales tendrá un solo tema.

Estas clases de afinidades y las técnicas para prevenir las anomalías son llamadas formas

normales. Dependiendo de su estructura, una afinidad puede estar en primera forma normal,

segunda forma normal o alguna otra. En su artículo Ted Codd, estableció la primera, segunda

y tercera forma normal. Cada una de estas formas están anidadas, esto es una afinidad que

está en tercera forma, debe estar en primera y segunda forma normal.

El modelo relacional para la gestión de una base de datos es un modelo de datos basado en

la lógica de predicados y en la teoría de conjuntos. Es el modelo más utilizado en la actualidad

para modelar problemas reales y administrar datos dinámicamente. Tras ser postuladas sus

bases en 1970 por Edgar Frank Codd, de los laboratorios IBM en San José (California), no

tardó en consolidarse como un nuevo paradigma en los modelos de base de datos.

Su idea fundamental es el uso de «relaciones».

Estas relaciones podrían considerarse en forma lógica como conjuntos de datos llamados

«tuplas». Pese a que ésta es la teoría de las bases de datos relacionales creadas por Edgar

Frank Codd, la mayoría de las veces se conceptualiza de una manera más fácil de imaginar,

esto es, pensando en cada relación como si fuese una tabla que está compuesta por registros

(cada fila de la tabla sería un registro o tupla), y columnas (también llamadas campos).



En este modelo todos los datos son almacenados en relaciones, y como cada relación es un

conjunto de datos, el orden en el que éstos se almacenen no tiene relevancia (a diferencia de

otros modelos como el jerárquico y el de red). Esto tiene la considerable ventaja de que es

más fácil de entender y de utilizar por un usuario no experto. La información puede ser

recuperada o almacenada por medio de consultas que ofrecen una amplia flexibilidad y poder

para administrar la información.

Este modelo considera la base de datos como una colección de relaciones. De manera

simple, una relación representa una tabla que no es más que un conjunto de filas, cada fila es

un conjunto de campos y cada campo representa un valor que interpretado describe el mundo

real. Cada fila también se puede denominar tupla o registro y a cada columna también se le

puede llamar campo o atributo.

Para manipular la información utilizamos un lenguaje relacional, actualmente se cuenta con

dos lenguajes formales el Álgebra relacional y el Cálculo relacional. El Álgebra relacional

permite describir la forma de realizar una consulta, en cambio, el Cálculo relacional sólo indica

lo que se desea devolver.

Esquema

Un esquema es la definición de una estructura (generalmente relaciones o tablas de una base

de datos), es decir, determina la identidad de la relación y que tipo de información podrá ser

almacenada dentro de ella; en otras palabras, el esquema son los metadatos de la relación.

Todo esquema constará de:

Nombre de la relación (su identificador).

Nombre de los atributos (o campos) de la relación y sus dominios; el dominio de un

atributo o campo define los valores permitidos para el mismo, es equivalente al tipo de

dato por ejemplo character, integer, date, string, etc.

Instancias

Una instancia de manera formal es la aplicación de un esquema a un conjunto finito de datos.

En palabras no tan técnicas, se puede definir como el contenido de una tabla en un momento

dado, pero también es válido referirnos a una instancia cuando trabajamos o mostramos

únicamente un subconjunto de la información contenida en una relación o tabla, como por

ejemplo:



4.2 Dominios atómicos y la primera forma normal.

La primera de las formas normales que se van a estudiar, la primera forma normal, impone un

requisito muy elemental a las relaciones; a diferencia de las demás formas normales, no exige

información adicional como las dependencias funcionales.

Un dominio es atómico si se considera que los elementos del dominio son unidades

indivisibles.

Una afinidad esta en primera forma normal, si la tupla tiene un campo definido como campo

clave y todos sus valores son atómicos para cada atributo en la relación. Esto es que los

valores de los atributos no pueden ser un conjunto de valores o un grupo repetitivo.

Cualquier tabla de datos que cumpla con la definición de una afinidad, se dice que está en

primera forma normal.

Si en la tabla encontramos grupos repetitivos es necesario crear una tabla de relación que

interrelacione a las tablas determinadas.

Cuando pasamos al modelo relacional debemos aplicar ciertas reglas las de estandarización,

de normalización del todo las tablas, a este conjunto de reglas se le conoce con el nombre de

normalización de base de datos, que consiste en aplicar una serie de relación las relaciones

obtenidas tras el paso del modelo entidad relación al modelo relacional. Las base de datos

relacionales se normalicen para evitar redundancia de los datos, evitar problemas de

actualización de los datos en las tablas, para proteger la integridad de los datos. Aquí es

importante mencionar que tenemos tres tipo de integridades, la integridad de dominio que

como dijimos anteriormente limita el conjunto de datos posibles en una columna. La integridad

de identidad, que establece que cada fila debe ser única y que no se permiten la duplicidad.

La integridad referencial que plantean que cuando un atributo columna de una tabla hace

referencia a la información de la tabla.



En el modelo relacional es común llamar tablas a una relación aunque para que una tabla sea

considerada tabla de una relación debe cumplir como algunas restricciones como que cada

tabla debe tener su nombre único, que no pueda haber dos filas iguales, que todos los datos

en una columna debe ser del mismo tipo. Para poder cumplir con estos enunciados se crearon

entonces la relación normalización que son seis reglas.

Normalización

El proceso de normalización de bases de datos consiste en aplicar una serie de reglas a las

relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional. Las bases

de datos relacionales se normalizan para:



La regla de normalización.

La primera regla de normalización dice que cada fila o tupla de una tabla la debe representar

una entidad y las entidades deben ser únicas, por lo que se debe establecer un atributo o

columna identifique de forma única cada registro de la tabla, esto se hace estableciendo una

llave primaria o clave principal.

De la misma de manera que un contribuyente tiene un número de identificación tributaria, de

la misma manera que un estudiante que lo número de carnet único, igual un vehículo tiene la

identificación parte del número de placa, de esa misma manera todo en otras tablas deben de

contar con una columna identifique de manera única cada fila de la tabla.

Repetimos, esto se logra estableciendo una llave primaria.

Si observamos la figura de nuestro ejemplo la llave primaria en este caso será el código, pero

la primera regla de normalización también dicen que los atributos de una tabla deben de ser

atómicos, esto quiere decir que un atributo debe de ser indivisible.



En nuestro ejemplo tengo el atributo nombre, pero en este caso existen nombres que se

componen de dos partes, por lo que en mi ejemplo el atributo no se puede considerar para

atómico ya que puede subdividirse e imprime el nombre segundo nombre, igual con los

apellidos, primer apellido segundo apellido, las direcciones están divididas en números, y

calles, avenidas, el número de casas. Por lo que dirección todavía se puede subdividir en

diferentes atributos. En este caso entonces no podemos considerar atómicos a los atributos

que acabo de mencionar.

La primera regla de normalización también dice que el orden de los datos no debe ser

relevante por lo tanto con Juan Elizandro que está como primer dato podría muy bien estar

cómodo si hago datos o como último dato, ya que el orden del ser irrelevante. Lo mismo

ocurre con los atributos, por ejemplo nombre podría estar como segundo atributo de la tabla o

como último, entonces la posición en la que estén los atributos no debe ser relevante



Repetimos, esto se logra estableciendo una llave primaria.

4.3 Dependencias funcionales

Hay veces en que los atributos están relacionados entre sí de manera más específica que la

de pertenecer a una misma relación. Hay veces en que es posible determinar que un atributo

depende de otro funcionalmente.

Las dependencias funcionales son restricciones de integridad sobre los datos. Conocer las

dependencias funcionales en el momento del diseño de la base de datos permite crear

mecanismos para evitar la redundancia (y los potenciales problemas de integridad que eso

conlleva) y mejorar la eficiencia.

Por ejemplo, sea la siguiente relación: Vehículo (serie, nombre, motor, carrocería, peso,

eficiencia). Aquí, serie es la llave. Por ende, hay solo un [modelo de] motor por serie, sólo una

[forma de] carrocería por serie, sólo un peso por serie y sólo una eficiencia [energética] por

serie: nombre = nombre (serie), motor = motor (serie), etcétera. O sea, serie → nombre,

motor, carrocera, peso, eficiencia (la relación es función de su llave; sólo hay una tupla por

llave).



Otra observación, que requiere mucho más conocimiento del problema, nos indica que la

eficiencia energética del vehículo es una función del motor, la carrocería y el peso.

Considerando esto, tenemos que motor, carrocera, peso → eficiencia. ¿Por qué? La eficiencia

energética consiste en la distancia que puede recorrer un vehículo por litro, a una velocidad

moderadamente alta. La potencia del vehículo reside en el motor: el modelo de motor indica la

fuerza que imprime el vehículo. Sin embargo, esta fuerza es contrarrestada por el roce

aerodinámico del vehículo, que es una función del roce viscoso del aire (es un dato fíjo) y de

la forma de la carrocería. Y el peso entrega la masa del vehículo (masa = 9, 8m/s 2 × peso). Si

se divide la fuerza resultante del vehículo por la masa, se obtiene la aceleración (y en un

equilibrio de velocidades se obtiene la eficiencia). Luego, existe una función tal que eficiencia

= eficiencia (motor, carrocera, peso).

¿Cómo obtener las dependencias funcionales?

La mejor manera de obtenerlas es a través del conocimiento del problema. Es lo más

disponible en la fase de diseño de una base de datos. Sin embargo, esto puede tornarse

bastante difícil, como en el caso del vehículo (honestamente, esto puede ocurrir cuando la

base de datos modela conocimiento técnico, que escapa al sentido común).

Otra manera, relacionada con el ejemplo anterior, es comprobar dependencias funcionales

sobre una gran población de datos usando la definición.

4.4 Segunda forma normal

La segunda forma normal (2NF) es una forma normal usada en normalización de bases de

datos. Una tabla que está en la primera forma normal (1NF) debe satisfacer criterios

adicionales para calificar para la segunda forma normal. Específicamente: una tabla 1NF está

en 2NF si y solo si, dada una clave primaria y cualquier atributo que no sea un constituyente

de la clave primaria, el atributo no clave depende de toda la clave primaria en vez de solo de

una parte de ella.

En términos levemente más formales: una tabla 1NF está en 2NF si y solo si ninguno de sus

atributos no-principales son funcionalmente dependientes en una parte (subconjunto propio)

de una clave primaria (Un atributo no-principal es uno que no pertenece a ninguna clave

primaria).



Observe que cuando una tabla 1NF no tiene ninguna clave candidata compuesta (claves

candidatas consistiendo en más de un atributo), la tabla está automáticamente en 2NF.

Ejemplo:

Considere una tabla describiendo las habilidades de los empleados:

Habilidades de los empleados


Empleado Habilidad Lugar actual de trabajo

Jones Mecanografía 114 Main Street

Jones Taquigrafía 114 Main Street

Jones Tallado 114 Main Street

Bravo Limpieza ligera 73 Industrial Way

Ellis Alquimia 73 Industrial Way

Ellis Malabarismo 73 Industrial Way

Harrison Limpieza ligera 73 Industrial Way

La única clave candidata de la tabla es {Empleado, Habilidad}.

El atributo restante, Lugar actual de trabajo, es dependiente solo en parte de la clave

candidata, llamada Empleado. Por lo tanto la tabla no está en 2NF. Observe la redundancia de

la manera en que son representadas los Lugares actuales de trabajo: nos dicen tres veces

que Jones trabaja en la 114 Main Street, y dos veces que Ellis trabaja en 73 Industrial Way.

Esta redundancia hace a la tabla vulnerable a anomalías de actualización:

Por ejemplo, es posible actualizar el lugar del trabajo de Jones en sus registros

"Mecanografía" y "Taquigrafía" y no actualizar su registro "Tallado". Los datos resultantes

implicarían respuestas contradictorias a la pregunta "¿Cuál es el lugar actual de trabajo de

Jones?".

Un alternativa 2NF a este diseño representaría la misma información en dos tablas:



Empleados

Empleado Lugar actual de trabajo

Jones 114 Main Street

Bravo 73 Industrial Way

Ellis 73 Industrial Way

Harrison 73 Industrial Way


Empleado Habilidad

Jones Mecanografía

Jones Taquigrafía

Jones Tallado

Bravo Limpieza ligera

Ellis Alquimia

Ellis Malabarismo

Harrison Limpieza ligera

Las anomalías de actualización no pueden ocurrir en estas tablas, las cuales están en 2NF.

Sin embargo, no todas las tablas 2NF están libres de anomalías de actualización. Un ejemplo

de una tabla 2NF que sufre de anomalías de actualización es:

Aunque el Ganador y la Fecha de nacimiento del ganador están determinadas por una clave

completa {Torneo, Año} y no son partes de ella, particularmente las combinaciones Ganador /

Fecha de nacimiento del ganador son mostradas redundantemente en múltiples registros.

Este problema es tratado por la tercera forma normal (3NF).



2NF y las claves candidatas

Una tabla para la cual no hay dependencias funcionales parciales en la clave primaria está

típicamente, pero no siempre, en 2NF. Además de la clave principal, la tabla puede contener

otras claves candidatas; es necesario establecer que ningún atributo no-principal tienen

dependencias de clave parciales en cualesquiera de estas claves candidatas.

Las múltiples claves candidatas ocurren en la siguiente tabla:

Aun si el diseñador ha especificado la clave principal como {Nombre completo del modelo}, la

tabla no está en 2NF. {Fabricante, Modelo} es también una clave candidata, y País del

fabricante es dependiente en un subconjunto apropiado de él: Fabricante.

4.5 Tercera forma normal

La tercera forma normal (3NF) es una forma normal usada en la normalización de bases de

datos. La 3NF fue definida originalmente por E.F. Codd1 en 1971. La definición de Codd

indica que una tabla está en 3NF si y solo si las dos condiciones siguientes se:

La tabla está en la segunda forma normal (2NF)

Ningún atributo no-primario de la tabla es dependiente transitivamente de una clave

primaria

Un atributo no-primario es un atributo que no pertenece a ninguna clave candidata. Una

dependencia transitiva es una dependencia funcional X → Z en la cual Z no es

inmediatamente dependiente de X, pero sí de un tercer conjunto de atributos Y, que a su vez

depende de X. Es decir, X → Z por virtud de X → Y e Y → Z.



Una formulación alternativa de la definición de Codd, dada por Carlo Zaniolo2 en 1982, es

ésta: Una tabla está en 3NF si y solo si, para cada una de sus dependencias funcionales X →

A, por lo menos una de las condiciones siguientes se mantiene:

X contiene A, ó

X es una superclave, ó

A es un atributo primario (es decir, A está contenido dentro de una clave candidata)

La definición de Zaniolo tiene la ventaja de dar un claro sentido de la diferencia entre la 3NF y

la más rigurosa forma normal de Boyce-Codd (BCNF). La BCNF simplemente elimina la

tercera alternativa ("A es un atributo primario").

Un ejemplo de una tabla 2NF que falla en satisfacer los requerimientos de la 3NF es:

La única clave candidata es {Torneo, Año}. La violación de la 3NF ocurre porque el atributo no

primario Fecha de nacimiento del ganador es dependiente transitivamente de {Torneo, Año}

vía el atributo no primario Ganador. El hecho de que la Fecha de nacimiento del ganador es

funcionalmente dependiente en el Ganador hace la tabla vulnerable a inconsistencias lógicas,

pues no hay nada que impida a la misma persona ser mostrada con diferentes fechas de

nacimiento en diversos registros.

Para expresar los mismos hechos sin violar la 3NF, es necesario dividir la tabla en dos:



Las anomalías de actualización no pueden ocurrir en estas tablas, las cuales están en 3NF.

La mayoría de las tablas 3NF están libres anomalías de actualización, inserción, y borrado.

Ciertos tipos de tablas 3NF, que en la práctica raramente se encuentran, son afectadas por

tales anomalías; éstas son tablas que no satisfacen la forma normal de Boyce-Codd (BCNF) o,

si satisfacen la BCNF, son insuficientes para satisfacer las formas normales más altas 4NF o

5NF.

4.6 Forma normal Boyce-Codd.

La Forma Normal de Boyce-Codd (o FNBC) es una forma normal utilizada en la normalización

de bases de datos. Es una versión ligeramente más fuerte de la Tercera forma normal (3FN).

La forma normal de Boyce-Codd requiere que no existan dependencias funcionales no

triviales de los atributos que no sean un conjunto de la clave candidata. En una tabla en 3FN,

todos los atributos dependen de una clave, de la clave completa y de ninguna otra cosa

excepto de la clave (excluyendo dependencias triviales, como). Se dice que una tabla está en

FNBC si y solo si está en 3FN y cada dependencia funcional no trivial tiene una clave

candidata como determinante. En términos menos formales, una tabla está en FNBC si está

en 3FN y los únicos determinantes son claves candidatas.

Consideremos una empresa donde un trabajador puede trabajar en varios departamentos. En

cada departamento hay varios responsables, pero cada trabajador sólo tiene asignado uno.

Tendríamos una tabla con las columnas:

IDTrabajador, IDDepartamento, IDResponsable



La única clave candidata es IDTrabajador (que será por tanto la clave primaria). Si añadimos

la limitación de que el responsable sólo puede serlo de un departamento, este detalle produce

una dependencia funcional ya que:

Responsable → Departamento

Por lo tanto hemos encontrado un determinante (IDResponsable) que sin embargo no es clave

candidata. Por ello, esta tabla no está en FNBC. En este caso la redundancia ocurre por mala

selección de clave. La repetición del par [IDDepartamento + IDResponsable] es innecesaria y

evitable.

Solamente en casos raros una tabla en 3NF no satisface los requerimientos de la FNBC. Un

ejemplo de tal tabla es (teniendo en cuenta que cada estudiante puede tener más de un tutor):

El propósito de la tabla es mostrar qué tutores están asignados a qué estudiantes. Las claves

candidatas de la tabla son:

{ID Tutor, ID Estudiante}

{Número de seguro social del tutor, ID Estudiante}

Una forma sencilla de comprobar si una relación se encuentra en FNBC consiste en

comprobar, además de que esté en 3FN, lo siguiente:

Si no existen claves candidatas compuestas (con varios atributos), está en FNBC.

Si existen varias claves candidatas compuestas y éstas tienen un elemento común, no

está en FNBC.



En la tabla de ejemplo anterior existen dos claves candidatas y ambas comparten el atributo

ID Estudiante, por lo tanto no está en FNBC.

4.7 Algoritmos de descomposición

Algoritmo de descomposición 3FN también se denomina algoritmo de síntesis de 3FN, ya que

toma un conjunto de dependencias y añade los esquemas uno a uno, en lugar de

descomponer el esquema inicial de manera repetida.

Algoritmo de descomposición FNBC, Recibe como argumentos:

1. El conjunto de dependencias funcionales (DF)

2. La relación original (r)* calculamos f+ * si el esquema no está en FNBC, usamos la primera

DEP funcional de DF no trivial que cumpla que la parte izquierda no sea clave candidata.*

dividimos el esquema r en dos: por un lado creamos un esquema cuyos atributos sean los de

la dependencia funcional y le añadimos aquellas dependencias funcionales de f+ que sólo

involucren a esos atributos.* y por otro lado creamos otro esquema cuyos atributos son todos

los de la relación.

R, menos los de la parte derecha de la dependencia funcional por la que estamos

descomponiendo, y le añadimos aquellas dependencias funcionales de f+ que solo involucren

a atributos de este segundo subesquema.*

El proceso es recursivo hasta que todos los esquemas estén en fnbc.atributos raros se dice

que un atributo de una dependencia funcional es raro si se puede eliminar sin modificar el

cierre del conjunto de dependencias funcionales.axiomas de armstrong.

Las dependencias funcionales verifican una serie de propiedades denominadas axiomas de

armstrong: reflexividad. A partir de cualquier atributo o conjunto de atributos siempre puede

deducirse él mismo. Dependencia trivial: x -> x. Aumentatividad. Si x -> y entonces x+z -> y.

Así se puede aumentar trivialmente el antecedente de una dependencia.

4.8 Formas normales superiores



Puede que en algunos casos el empleo de las dependencias funcionales para la

descomposición de los esquemas no sea suficiente para evitar la repetición innecesaria de

información. Considérese una ligera variación de la definición del conjunto de entidades

empleado en la que se permite que los empleados tengan varios números de teléfono, alguno

de los cuales puede ser compartido entre varios empleados.

Entonces, numero_telefono será un atributo multivalorado y, de acuerdo con las reglas para la

generación de esquema a partir de los diseños E-R, habrá dos esquemas, uno por cada uno

de los atributos multivalorados numero_telefono y nombre_subordinado:

(id_empleado,nombre_subordinado)(id_empleado,numero_telefono)

Si se combinan estos esquemas para obtener

(id_empleado,nombre_subordinado,numero_telefono)

Se descubre que el resultado se halla en la FNBC, ya que solo se cumplen dependencias

funcionales no triviales. En consecuencia, se puede pensar que ese tipo de combinación es

una buena idea. Sin embargo se trata de una mala idea, como puede verse si se considera el

ejemplo de un empleado con dos subordinados y dos números de teléfono. Por ejemplo, sea

el empleado con id_empleado 9999999999 que tiene dos subordinados llamados “David” y

“Guillermo” y dos números de teléfono, 512555123 y 512555432. En el esquema combinado

hay que repetir los números de teléfono una vez por cada subordinado:

(9999999999, David, 512555123)

(9999999999, David, 512555432)

(9999999999, Andres, 512555123)

(9999999999, Andres, 512555432)

Si no se repitieran los números de teléfonos y solo se almacenaran la primera y la última tupla,

se habrían guardado el nombre de los subordinados y los números de teléfono, pero las tuplas

resultantes implicarían que David correspondería al 512555123 y que Andrés correspondería

al 512555432. Como sabemos, esto es incorrecto.



Debido a que las formas normales basadas en las dependencias funcionales no son

suficientes para tratar con sustituciones como esta, se han definido otras dependencias y

formas normales.

4.9 Integridad de las bases de datos

Integridad de las Bases de Datos, la integridad en una base de datos es la corrección y

exactitud de la información contenida. Además de conservar la seguridad en un sistema de

bases de datos que permite el acceso a múltiples usuarios en tiempos paralelos.

Condiciones de la Integridad

Las condiciones que garantizan la integridad de los datos pueden ser de dos tipos:

Las restricciones de integridad de usuario: son condiciones específicas de una base de datos

concreta; son las que se deben cumplir en una base de datos articular con unos usuarios

concretos, pero que no son necesariamente relevantes en otra Base de Datos.

Las reglas de integridad de modelo: son condiciones propias de un modelo de datos, y se

deben cumplir en toda base de datos que siga dicho modelo.

Los SGBD deben proporcionar la forma de definir las restricciones de integridad de usuario de

una base de datos y una vez definida, debe velar por su cumplimiento. Las reglas de

integridad del modelo, en cambio, no se deben definir para cada base de datos concreta,

porque se consideran preestablecidas para todas las base de datos de un modelo. Un SGBD

de un modelo determinado debe velar por el cumplimiento de las reglas de integridad

preestablecidas por su modelo.

Reglas de Integridad Regla de integridad de unicidad de la clave primaria

La regla de integridad de unicidad está relacionada con la definición de clave primaria que

establece que toda clave primaria que se elija para una relación no debe tener valores

repetidos por lo que el conjunto de atributos CP es la clave primaria de una relación R,

entonces la extensión de R no puede tener en ningún momento dos tuplas con la misma

combinación de valores para los atributos de CP.

Regla de integridad de entidad de la clave primaria



La regla de integridad de entidad de la clave primaria dispone que los atributos de la clave

primaria de una relación no pueden tener valores nulos. Esta regla es necesaria para que los

valores de las claves primarias puedan identificar las tuplas individuales de las relaciones. Si

las claves primarias tuviesen valores nulos, es posible que algunas tuplas no se pudieran

distinguir. Un SGBD relacional tendrá que garantizar el cumplimiento de esta regla de

integridad en todas las inserciones y en todas las modificaciones que afecten a atributos que

pertenecen a la clave primaria de la relación.

Regla de integridad referencial

La regla de integridad referencial está relacionada con el concepto de clave foránea, lo que

determina que todos los valores que toma una clave foránea deben ser valores nulos o

valores que existen en la clave primaria que referencia. La necesidad de esta regla es debido

a que las claves foráneas tienen por objetivo establecer una conexión con la clave primaria

que referencian. Si un valor de una clave foránea no estuviese presente.

Restricción

La restricción en caso de borrado, consiste en no permitir borrar una tupla si tiene una clave

primaria referenciada por alguna clave foránea y la restricción en caso de modificación

consiste en no permitir modificar ningún atributo de la clave primaria de una tupla si tiene una

clave primaria referenciada por alguna clave foránea.

Actualización en cascada

La actualización en cascada consiste en permitir la operación de actualización de la tupla, y en

efectuar operaciones compensatorias que propaguen en cascada la actualización a las tuplas

que la referenciaban; se actúa de este modo para mantener la integridad referencial. La

actualización en cascada en caso de borrado consiste en permitir el borrado de una tupla t

que tiene una clave primaria referenciada, y borrar también todas las tuplas que referencian t y

la actualización en cascada en caso de modificación consiste en permitir la modificación de

atributos de la clave primaria de una tupla t que tiene una clave primaria referenciada, y

modificar del mismo modo todas las tuplas que referencian t.

Anulación

La anulación consiste en permitir la operación de actualización de la tupla y en efectuar

operaciones compensatorias que pongan valores nulos a los atributos de la clave foránea de



las tuplas que la referencian; esta acción se lleva a cabo para mantener la integridad

referencial. Los SGBD relacionales permiten establecer que un determinado atributo de una

relación no admite valores nulos, sólo se puede aplicar la política de anulación si los atributos

de la clave foránea sí los admiten. Más concretamente, la anulación en caso de borrado

consiste en permitir el borrado de una tupla t que tiene una clave referenciada y, además,

modificar todas las tuplas que referencian t, de modo que los atributos de la clave foránea

correspondiente tomen valores nulos y la anulación en caso de modificación consiste en

permitir la modificación de atributos de la clave primaria de una tupla t que tiene una clave

referenciada y, además, modificar todas las tuplas que referencian t, de modo que los

atributos de la clave foránea correspondiente tomen valores nulos.

Regla de integridad de dominio

La regla de integridad de dominio está relacionada con la noción de dominio. Esta regla

establece dos condiciones.

La primera condición consiste en que un valor no nulo de un atributo Ai debe

pertenecer al dominio del atributo Ai; es decir, debe pertenecer a dominio(Ai). Esta

condición implica que todos los valores no nulos que contiene la base de datos para

un determinado atributo deben ser del dominio declarado para dicho atributo.

La segunda condición sirve para establecer que los operadores que pueden

aplicarse sobre los valores dependen de los dominios de estos valores; es decir, un

operador determinado sólo se puede aplicar sobre valores que tengan dominios que le

sean adecuados.



REFERENCIAS

Bibliográficas

Electrónicas

http://orlandotlilayatzi.wikispaces.com/UNIDAD+1

http://www.estructurayprogramacion.com/materias/fundamentos-de-base-

de-datos/t%C3%B3picos-selectos-de-bases-de-datos/

http://www.marcoteorico.com/curso/31/fundamentos-de-bases-de-datos#423

http://www.estructurayprogramacion.com/materias/fundamentos-de-base-

de-datos/


http://www.estructurayprogramacion.com/materias/fundamentos-de-base-de-datos/

http://www.estructurayprogramacion.com/materias/fundamentos-de-base-de-datos/

http://www.marcoteorico.com/curso/31/fundamentos-de-bases-de-datos#423

http://www.estructurayprogramacion.com/materias/fundamentos-de-base-de-datos/t%C3%B3picos-selectos-de-bases-de-datos/

http://www.estructurayprogramacion.com/materias/fundamentos-de-base-de-datos/t%C3%B3picos-selectos-de-bases-de-datos/

http://orlandotlilayatzi.wikispaces.com/UNIDAD+1

Documents

Antologia 4A JEMIMA