Atributos y Dominios

1.Atributos

1.1 Definición

En bases de datos, un atributo representa una propiedad de interés de una entidad.

Los atributos se describen en la estructura de la base de datos empleando un modelo de datos.

Por ejemplo, se podría tener una entidad llamada "Alumno". Esta entidad puede estar constituida por uno o más atributos, que son propiedades de la entidad "Alumno" que interesan para almacenarse en la base de datos. Por ejemplo, la entidad "Alumno" podría tener los atributos: nombre, apellido, año de nacimiento, etc.

La elección de los atributos de una entidad depende del uso que se le dará a la base de datos. El alumno puede tener una "religión", pero si no interesa al fin de la base de datos, no es necesario almacenarla en un atributo.

En SQL un atributo es llamado columna.

1.2 Características

Cada atributo de una relación se caracteriza por un nombre y por un dominio. El dominio indica qué valores pueden ser asumidos por una columna de la relación. A menudo un dominio se define a través de la declaración de un tipo para el atributo (por ejemplo diciendo que es una cadena de diez caracteres), pero también es posible definir dominios más complejos y precisos. Por ejemplo, para el atributo "sexo" de nuestra relacion "Personas" podemos definir un dominio por el cual los únicos valores válidos son 'M' y 'F'; o bien por el atributo "fecha_nacimiento" podremos definir un dominio por el que se consideren válidas sólo las fechas de nacimiento después del uno de enero de 1960, si en nuestra base de datos no está previsto que haya personas con fecha de nacimiento anterior a esa.

2.Dominios

2.1 Definición

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

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

2.2 Características

Característica fundamental de los dominios de una base de datos relacional es que sean "atómicos", es decir que los valores contenidos en las columnas no se puedan separar en valores de dominios más simples. Más formalmente se dice que no es posible tener atributos multivalor (multivalued). Por ejemplo, si una característica de las personas en nuestra base de datos fuese la de tener uno o más hijos, no sería posible escribir la relación Personas de la siguiente manera:

Personas (nombre, apellido, fecha_nacimiento, sexo, estado_civil, hijos)

Teoría de Relaciones II

1.Recursivas

En las bases de datos relacionales, cuando una tabla se relaciona consigo misma, este tipo de relación recibe el nombre de relación recursiva. Por ejemplo, en una relación supervisor-supervisado, una tabla que almacena los registros de empleados se relaciona consigo misma. En este caso, la tabla de empleados desempeña una función de supervisor en uno de los lados de la relación y una función de supervisado en el otro lado.

Los esquemas de asignación pueden incluir relaciones recursivas donde un elemento y su antecesor son del mismo tipo.

2.Entidades Asociativas

La entidad que resulta de considerar una interrelación entre entidades como si fuese una entidad es una entidad asociativa, y tendrá el mismo nombre que la interrelación sobre la que se define.

La utilidad de una entidad asociativa consiste en que se puede interrelacionar con otras entidades y, de forma indirecta, nos permite tener interrelaciones en las que intervienen interrelaciones. Una entidad asociativa se denota recuadrando el rombo de la interrelación de la que proviene.

Ejemplo:

Recorrido es una interrelación de conectividad M:N que registra las ciudades por donde han pasado los diferentes viajes organizados por una empresa de reparto de paquetes. Consideramos recorrido una entidad asociativa con el fin de interrelacionarla con la entidad cliente; de este modo nos será posible reflejar por orden de qué clientes se han hecho repartos en una ciudad del recorrido de un viaje, así como el número de paquetes cargados y descargados siguiendo sus indicaciones.

El mecanismo de las entidades asociativas subsume el de las entidades débiles

y resulta todavía más potente. Es decir, siempre que utilicemos una entidad débil podremos sustituirla por una entidad asociativa, pero no al revés.

Ejemplo de sustitución de una entidad débil por una asociativa:

3.Dependencias Funcionales

Una dependencia funcional es una conexión entre uno o más atributos. Por ejemplo si se conoce el valor de FechaDeNacimiento podemos conocer el valor de Edad.

Las dependencias funcionales del sistema se escriben utilizando una flecha, de la siguiente manera:

FechaDeNacimiento es a Edad

Aquí a FechaDeNacimiento se le conoce como un determinante. Se puede leer de dos formas FechaDeNacimiento determina a Edad o Edad es funcionalmente dependiente de FechaDeNacimiento. De la normalización (lógica) a la implementación (física o real) puede ser sugerible tener éstas dependencias funcionales para lograr la eficiencia en las tablas.

Propiedades de la Dependencia funcional

Existen 3 axiomas de Armstrong:

1.Dependencia funcional Reflexiva

Si "x" está incluido en "x" entonces x es a x A partir de cualquier atributo o conjunto de atributos siempre puede deducirse él mismo. Si la dirección o el nombre de una persona están incluidos en el DNI, entonces con el DNI podemos determinar la dirección o su nombre.

2.Dependencia funcional Aumentativa

X es a Y entonces XZ es a YZ

DNI es a nombre

DNI,dirección es a nombre,dirección

Si con el DNI se determina el nombre de una persona, entonces con el DNI más la dirección también se determina el nombre y su dirección.

3.Dependencia funcional transitiva.

Sean X, Y, Z tres atributos (o grupos de atributos) de la misma entidad. Si Y depende funcionalmente de X y Z de Y, pero X no depende funcionalmente de Y, se dice entonces que Z depende transitivamente de X. Simbólicamente sería:

X es a Y es a Z entonces X es a Z

FechaDeNacimiento es a Edad

Edad es a Conducir

FechaDeNacimiento es a Edad es a Conducir

Entonces tenemos que FechaDeNacimiento determina a Edad y la Edad determina a Conducir, indirectamente podemos saber a través de FechaDeNacimiento a Conducir (En muchos países, una persona necesita ser mayor de cierta edad para poder conducir un automóvil, por eso se utiliza este ejemplo).

Teoría de Relaciones I

CARDINALIDAD

Relación o Asociación

• Expresa una asociación entre ocurrencias deentidad

• Puede tener atributos propios

• Grado: número de entidades que asocia

• Cardinalidad:

Número de ocurrencias de una entidad que puedenasociarse con otra entidad

– Máxima - 1:1, 1:N, N:1, N:M

– Mínima - 0:0, 1:0, 0:1, 1:1

TIPOS DE RElaCIONES

Existen 3 tipos de relaciones:

1. De Uno a Uno

2. De Uno a Varios

3. De Varios a Varios

Diagrama E/R(Entidad/Relacion) III

MODELO FÍSICO

El paso de un modelo lógico a uno físico requiere un profundo entendimiento del manejador de bases de datos que se desea emplear, incluyendo características como:

Conocimiento a fondo de los tipos de objetos (elementos) soportados

Detalles acerca del indexamiento, integridad referencial, restricciones, tipos de datos, etc

Detalles y variaciones de las versiones

Parámetros de configuración

Data Definition Language (DDL)

Como se comentó en el modelado lógico el paso de convertir el modelo a tablas hace que las entidades pasen a ser tablas (más las derivadas de las relaciones) y los atributos se convierten en las columnas de dichas tablas.

Físicamente esta metáfora de una tabla se mapea al medio físico, con algunas consideraciones como se menciona en las siguientes secciones.

1. Atributos

1.1 Tipos de Datos

Revisar los tipos de datos disponibles en el DBMS, en especial

Número de dígitos en números enteros

La precisión de los flotantes

Cadenas de caracteres de longitud fija (char(50)) y variable (varchar(50))

Blobs (Binary large objects) y Clobs (Character large objects)

1.2 Llaves primarias

En ocasiones se pueden presentar casos en donde la llave primaria no puede representarse en alguno de los tipos ofrecidos por el dbms, en ese caso se podria definir alguno y bien optar por otra llave primaria.

Importante:

Algunos dbms poseen la capacidad de "autoincrement" o "identity property" con la cual pueden automáticamentemanipular algun atributo para generar llaves incrementales. Pero es importante verificar: como se manejan internamente ?, se pueden reiniciar ?, se permite especificar algun valor inicial ?.

1.3 Orden de las atributos (columnas)

Algo importante dependiendo del dbms que se utilice pero por lo general la secuencia es:

Columnas de longitud fija que no se actualizan frecuentemente.

Aquellas que nunca se actualizan que por lo general tendrán longitud variable.

Las que se actualizan frecuentemente.

1.4 Integridad Referencial

En la medida de lo posible indicar cuales columnas brindan o sirven de vínculo entre 2 tablas.

El usuario (programador) puede hacerse cargo de esto pero es mejor que el dbms se haga cargo.

No se recomienda en ambientes de desarrollo.

Modelo E/R(Entidad/Relación) II

MODELO LÓGICO

El objetivo del diseño lógico es convertir los esquemas conceptuales locales en un esquema lógico global que se ajuste al modelo de SGBD sobre el que se vaya a implementar el sistema. Mientras que el objetivo fundamental del diseño conceptual es la compleción y expresividad de los esquemas conceptuales locales, el objetivo del diseño lógico es obtener una representación que use, del modo más eficiente posible, los recursos que el modelo de SGBD posee para estructurar los datos y para modelar las restricciones

Los modelos de bases de datos más extendidos son el modelo relacional, el modelo de red y el modelo jerárquico. El modelo orientado a objetos es también muy popular, pero no existe un modelo estándar orientado a objetos.

El modelo relacional (y los modelos previos) carecen de ciertos rasgos de abstracción que se usan en los modelos conceptuales. Por lo tanto, un primer paso en la fase del diseño lógico consistirá en la conversión de esos mecanismos de representación de alto nivel en términos de las estructuras de bajo nivel disponibles en el modelo relacional.

Metodología de diseño lógico en el modelo relacional

La metodología que se va a seguir para el diseño lógico en el modelo relacional consta de dos fases, cada una de ellas compuesta por varios pasos que se detallan a continuación.

1. Construir y validar los esquemas lógicos locales para cada vista de usuario.

2. Convertir los esquemas conceptuales locales en esquemas lógicos locales.

3. Derivar un conjunto de relaciones (tablas) para cada esquema lógico local.

4. Validar cada esquema mediante la normalización.

5. Validar cada esquema frente a las transacciones del usuario.

6. Dibujar el diagrama entidad-relación.

7. Definir las restricciones de integridad.

7. Revisar cada esquema lógico local con el usuario correspondiente.

8. Construir y validar el esquema lógico global.

9. Mezclar los esquemas lógicos locales en un esquema lógico global.

10. Validar el esquema lógico global.

11. Estudiar el crecimiento futuro.

12. Dibujar el diagrama entidad-relación final.

13. Revisar el esquema lógico global con los usuarios.

En la primera fase, se construyen los esquemas lógicos locales para cada vista de usuario y se validan. En esta fase se refinan los esquemas conceptuales creados durante el diseño conceptual,

eliminando las estructuras de datos que no se pueden implementar de manera directa sobre el modelo que soporta el SGBD, en el caso que nos ocupa, el modelo relacional. Una vez hecho esto, se obtiene un primer esquema lógico que se valida mediante la normalización y frente a las transacciones que el sistema debe llevar a cabo, tal y como se refleja en las especificaciones de

requisitos de usuario. El esquema lógico ya validado se puede utilizar como base para el desarrollo de prototipos. Una vez finalizada esta fase, se dispone de un esquema lógico para cada

vista de usuario que es correcto, comprensible y sin ambigüedad