Base de Datos AVANZADOS

Gestión de bases de datos no SQL, datos temporales, datos espaciales, datos en la web.

El objetivo de este libro es presentar a los estudiantes una introducción a las nuevas tendencias en bases de datos soportadas por la evolución de la tecnología informática, que contemplan la gestión de nuevos tipos de datos. La propuesta está dirigida a segundas asignaturas de Bases de Datos y cubre temas tales como la gestión de bases de datos no SQL, datos temporales, datos espaciales, datos en la web, la recuperación de información documental, la creación de repositorios para ayudar a la toma de decisiones, incluyendo una introducción a técnicas y herramientas para analizar estos datos. Los capítulos“Sistemas de Recuperación de Información”,“Bases de Datos y Web”,,“Datos Temporales y Datos Espaciales”, y “Sistemas de ayuda a la toma de decisión”, son aportes de Cristina Bendery Claudia Deco. Juan Sebastián González Sanabria es autor del capítulo “Diseño de Bases de Datos”. El capítulo “Bases de Datos No SQL”fue escrito por Marí".

Diseño de Bases de Datos

Introducción

Con la aparición de nuevas tecnologías para la gestión de bases de datos, en algunas ocasiones se ha dejado de lado el diseño y modelado de las bases de datos relacionales, las cuales, a hoy, aún siguen siendo las de mayor uso. Es por lo anterior que el capítulo se enfoca en presentar desde un punto de vista simple las consideraciones a tener en cuenta en el ciclo de vida de desarrollo de bases de datos relacionales, aplicando estándares y normas de calidad aprobadas por diferentes entes expertos en la temática como la Organización Internacional de Estándares ISO (por las siglas en ingles de International Organization for Standardization). El ciclo de vida de las bases de datos va desde el proceso de analizar la problemática hasta la implementación de la solución planteada, pero para el presente capitulo se limitará al llamado esquema o modelo entidad relación, en su fase conceptual, lógica y física, sin dejar de lado otros aspectos necesarios para el diseño. Para el adecuado entendimiento del tema, se iniciará con el Modelo ER y los elementos que lo componen, continuando con el ciclo de vida de las bases de datos, y ﬁnalizando con algunos estándares para el diseño.

Modelado Entidad-Relación (ER)

El modelado Entidad – Relación se plantea por primera vez en artículos publicados por Peter P. Chen en la década de los setenta, donde inicialmente se divulgó como Modelo Entidad – Interrelación, pero posteriormente a traducciones adecuadas y hasta el día de hoy se le conoce como Modelo Entidad – Relación. Posterior a la década en mención son diversos los autores y expertos que han hecho aportes y cambios al modelo planteado por Chen, motivo en el que radica la diﬁcultad de que no exista a nivel internacional una notación estándar para este modelado. Sin embargo Richard Barker, junto a otros expertos como Ian Palmer, Harry Ellis, propusieron alrededor del año 1981 algunos aportes y cambios que fueron bien recibidos, haciendo que la notación Barker, en honor a su principal expositor, para modelado Entidad – Relación sea la más utilizada en el contexto internacional por sus diferentes beneﬁcios en la interpretación y “lectura” del Modelo. Es de aclarar que en algunos países la notación Barker también es conocida como la notación “Pata de gallina”, por la traducción latina de “crows foot". Ahora bien, ¿Por qué hacer uso del modelo ER?, la respuesta a este interrogante es simple: El modelo permite una robusta representación de la totalidad la información que se requiere para la base de datos, eliminando redundancias y siendo el punto de partida para socializar con el cliente o usuario ﬁnal, pues el modelo es de fácil interpretación por parte de este, al presentar una visión simpliﬁcada del negocio.

Elementos del Modelo ER

El Modelo ER cuenta con diferentes elementos, estos diﬁeren mayormente en su forma de representación de acuerdo a la notación seleccionada, para el caso cabe recalcar que se utilizará la Notación Barker. Los elementos más signiﬁcativos son:

Entidades
Atributos
Relaciones

Entidades

Una Entidad se puede deﬁnir “algo” de importancia dentro del sistema a desarrollar de lo que interesa almacenar todos los datos. Generalmente se suelen deﬁnir objetos(carros,personas,entre otros) y eventos (compras, ventas); aunque se debe aclarar que muchos de los eventos, suelen representarse dentro del sistema con objetos (por ejemplo, una venta se representa mediante una factura). La representación de las entidad es se realiza mediante un rectángulo con sus puntas ovaladas, también conocido como rectángulo suavizado.Cada entidad debe poseer un nombre único dentro del modelo y darse en mayúscula.

Es de anotar que el nombre de la entidad para el diseño conceptual se suele representar en singular, y para los siguientes (lógica y física) en plural. Adicionalmente pese a que no existe un tamaño estándar de las entidades, por buenas prácticas de diseño y para facilidad de entendimiento se recomienda que todas las entidades del modelo conserven proporciones similares. Las Entidades se deben diferenciar de las INSTANCIAS, las cuales corresponden a los valores que puede tener un atributo, en el Cuadro 1.1 se presentan algunos ejemplos de atributos con sus posibles instancias.

En resumen se puede deﬁnir que una entidad representa un conjunto de instancias con un interés común dentro de la lógica del sistema. Existen dos tipos fundamentales de entidades:
Entidades Fuertes
Entidades Débiles

Entidades Fuertes:

En ocasiones también llamadas entidades regulares, son aquellas que se identiﬁcan por sí mismas, es decir, no requieren de otra entidad para existir.

Entidades Débiles:

Para existir dentro del modelo depende de otras entidades. Por ejemplo una entidad HISTORIA_LABORAL solo podría existir si se cuenta con la entidad EMPLEADO y la entidad CARGO. Una entidad débil puede depender de una o muchas entidades. La representación de las entidades débiles en el modelo se hace con una línea adjunta a la relación, como se ilustra en la

Estas entidades débiles suelen aparecer cuando hay atributos asociados a las relaciones.

Atributos

Los Atributos, dentro del contexto del Modelo ER, son conocidos como las características de la entidad, aquello que le da propiedades (por ejemplo, el primero nombre, el primer apellido, la fecha de nacimiento de una Persona); los atributos se usan para describir, cuantiﬁcar, caliﬁcar o clasiﬁcar una entidad. Los atributos deben ser consecuentes con el principio de Atomicidad de las bases de datos, es decir deben tener un único valor. Adicionalmente todo atributo debe corresponder o asociarse a un tipo de dato (texto, numero, fecha, entre otros). Para representar los atributos en el Modelo ER se escribe el nombre del atributo (singular) dentro de en la entidad en letra minúscula, en caso de que el nombre del atributo sea compuesto por dos o más palabras, el espacio se remplaza por guion bajo (_), A continuación se presentan ejemplos de algunos atributos asociados a entidades.
Igual que en el caso de las entidades, también se deben diferenciar INSTANCIAS de ATRIBUTOS, por ejemplo.

Los atributos se clasiﬁcan en tres tipos:

Llave Primaria
Atributo Obligatorio
Atributo Opcional.

Llave primaria:

Las llaves primarias son aquellas que le brindan una identidad dentro del modelo a la entidad, es aquel atributo cuya INSTANCIA (Valor que puede tomar un atributo) no se va a repetir en ningún caso, como lo puede ser el número de identiﬁcación nacional de una persona, el número de matrícula de un carro. Las llaves primarias se representan con el símbolo numeral (#) al lado del nombre del atributo.

Atributo Obligatorio:

Los atributos obligatorios corresponden a todos los datos que se requieren conocer dentro del contexto del sistema, como puede ser el nombre, el apellido, la dirección y el teléfono de una persona en el caso de un formulario de contacto. Los atributos obligatorios se representan con el símbolo asterisco (*) al lado del

Atributo Opcional:

Corresponden a aquellos datos que podrían llegar a requerirse a futuro o que pueden no tener siempre un valor de instancia requerido, es decir el almacenamiento de estos atributos no inﬂuye en el funcionamiento del sistema. Los atributos opcionales se representan con un círculo (o) al lado del nombre del atributo.

Modelado Entidad-Relación (ER)

TIP1:Aunque algunos autores sugieren que para el caso de las llaves primarias, al ser también atributos obligatorios, deben representarse con los dos símbolos antes del nombre del atributo; a término de experiencia se sobre entiende que al ser llave es un atributo obligatorio por lo que basta con representarse con el símbolo de numeral.

TIP 2: Si un atributo es opcional u obligatorio, se deﬁne por el contexto del sistema que se desarrollará, por tanto en un sistema el atributo teléfono puede ser opcional y en otro obligatorio.

TIP3:Los atributos de un sistema pueden ser considerados como entidades en otro sistema, y viceversa; lo anterior de acuerdo al CONTEXTO en el que se desarrolle.

TIP 4: Se debe tener especial cuidado con los campos que son calculados a partir de otros campos, estos son conocidos como CAMPOS VIRTUALES y no se sugiere almacenarlos o representarlos en el modelo.

Relaciones

Las relaciones, por redundante que pueda escribirse, representan el cómo las entidades se relacionan entre sí, es decir los vínculos que existen entre los diferentes objetos y eventos que conforman el negocio. Se representan en el modelo mediante líneas que se componen de dos partes fundamentales el grado y la opcionalidad.

Opcionalidad:
Hace referencia a si la relación puede o debe existir, si la relación debe existir se representa mediante línea continua, si la relación puede existir se representa con una línea punteada.

Grado:

Se reﬁere al número de veces que se puede llegar a relacionar una entidad con otra. Es de su representación de donde se conoce como la notación para Modelado ER de “Pata de gallina”, los grados a representarse son los siguientes:
Posterior a estos dos elementos las diferentes combinaciones permiten diez posibles relaciones entre entidades.

A las relaciones se le suelen dar dos perspectivas (nombres de la relación), esto con el ﬁn de dar una adecuada lectura a las relaciones y el modelo sea lo más entendible posible. La lectura de las relaciones se realiza en el siguiente orden Entidad–Opcionalidad–Grado– Entidad, en el siguiente ejemplo se explica de mejor manera:

Otros Elementos

Existen una serie de elementos que han surgido para complementar el modelo ER para una mayor interpretación y aproximación a la realidad del sistema. Entre estos elementos cabe destacar los siguientes:

Subtipos:

Los subtipos, también conocidos como subentidades, se incluyen dentro del modelo cuando existen entidades que tienen propiedades en común y que comparten atributos; por ejemplo, las entidades Profesor y Estudiante, pueden ser subtipos de una entidad Persona.Estos se representan con Entidades dentro de una Entidad, esta última conocida como Superentidad.

Arcos o Relaciones de Exclusividad:
Este tipo de relación expresa que no es posible que exista relación simultánea de una instancia de una entidad con las instancias de las entidades que participan en la relación de exclusividad o en el arco. Es de anotar que se les llama arcos debido a su representación dentro del modelo. A continuación se presenta un ejemplo de uso de estas relaciones.

El ejemplo representa que una instancia de la entidad Factura le corresponde a una instancia de la entidad Persona o una instancia de Empresa, pero nunca a las dos al mismo tiempo. Se deben tener en cuenta algunas normas al momento de hacer uso de las relaciones exclusivas, estas son:

Solo le pertenece a una entidad, es decir tal y como se presenta el ejemplo, si el arco se modelara en el lado contrario al del ejemplo, esto sería erróneo.
Puede involucrar de dos a n relaciones
No necesariamente debe excluir a todas las relaciones que llegan a la entidad, pero si siempre a mínimo dos.
Las relaciones incluidas en el arco deben tener la misma opcionalidad

SIGUE APRENDIENDO DESCARGANDO EL ARCHIVO