Diseño Conceptual de Una Base de Datos
August 4, 2022 | Author: Anonymous | Category: N/A
Short Description
Download Diseño Conceptual de Una Base de Datos ...
Description
República Bolivariana de Venezuela Ministerio del Poder Popular para la Educación Superior, Ciencia y Tecnología Universidad Politécnica Territorial del Alto Apure Pedro Camejo Mantecal – Apure Apure INTENSVO
Diseño Conceptual de una Base de Datos (Taller)
Docente: Maira Santana
Participante: Adalmerys Rodríguez C.I. 16.527.572
San Fernando, 24 de agosto de 2021
DEFINICIÓN DE MODELO CONCEPTUAL CONCEPTUAL Un modelo conceptual es un lenguaje que se utiliza para describir esquemas conceptuales. El objetivo del diseño conceptual es describir el contenido de información de la base de datos y no las estructuras de almacenamiento que se necesitarán para manejar esta formación, es decir que el modelado conceptual permite describir, de un modo totalmente independiente de la implementación, los datos que el usuario quiere recoger en el sistema. Esto va a depender de la cantidad de información que se desee representar, tendremos aplicaciones más o menos orientadas a los datos. Así, por ejemplo, la gestión de una biblioteca es una aplicación pura de Bases de D Datos atos (en adelante BD) ya qu quee prácticamente toda la funcionalidad del sistema se centra en el mantenimiento de los datos (introducir un libro, prestar un libro, etc.). Existen, sin embargo, otras aplicaciones, como por ejemplo un sistema de control de navegación aérea, en las que los datos son algo secundario. Podemos decir que, en general, los datos son el núcleo de todo SI orientado a la gestión. En este mismo sentido, el modelado conceptual es una actividad que se realiza en la etapa de análisis, paralelamente al modelado de procesos o funciones. Su objetivo, como ya hemos dicho, es captar toda la información del mundo real que se desea representar en el mundo informático. En este proceso es importante abstraer los detalles sin importancia y representar tan sólo aquella información que sea relevante y en los cuales se podrán utilizar distintos mecanismos de persistencia de los datos: Sistemas de Bases de Datos, Sistemas de Ficheros, entre otros.
MODELADO DE BASE DE DATOS Un modelo de base de datos (Data Información Estructurada) es un tipo de modelo de datos que determina la estructura lógica de una base de datos y de manera fundamental determina el modo de almacenar, organizar y manipular los datos. Entre los modelos lógicos comunes para bases de datos se encuentran: Modelo jerárquico: Un modelo de datos jerárquico es un modelo de datos en el cual
los datos son organizados en una u na estructura parecida a un árbol. La estructura permite a la información que se repite y usa relaciones padre/Hijo: cada padre puede tener
muchos hijos pero cada hijo sólo tiene un padre. Todos los atributos de un registro específico son catalogados bajo un tipo de entidad; siendo el tipo de entidad el equivalente de una tabla, donde cada registro individual es representado como una fila y un atributo como una columna. Los tipos de entidad son relacionados el uno con el otro usando 1: Trazar un mapa de n, también conocido como relación de uno a varios. Un ejemplo de un modelo de datos jerárquico sería si una organización tuviera los registros de empleados en una tabla (el tipo de entidad) llamada "Empleados". En la tabla habría atributos/columnas como el Nombre de pila, el Apellido, el Nombre de Trabajo y el Salario. La empresa también tiene datos sobre los hijos del empleado en una tabla separada "Hijos" llamada con atributos como el Nombre de pila, el Apellido, y la fecha de nacimiento. La tabla de Empleado representa un segmento paternal y la tabla de Hijos representa un segmento Infantil. Estos dos segmentos forman una jerarquía donde un empleado puede tener muchos hijos, pero cada hijo sólo puede tener un padre. datos conformada por una Modelo en red: Una base de datos de red es una base de datos
colección o set de registros, los cuales cu ales están conectados entre sí por medio de enlaces en una red. El registro es similar al de una entidad como las empleadas en el modelo relacional. En donde un registro es una colección o conjunto de campos (atributos), donde cada uno de ellos contiene solamente un único valor almacenado. El enlace es exclusivamente la asociación entre dos registros, así que podemos verla como una relación estrictamente binaria. Una estructura de base de datos de red, llamada algunas veces estructura de plex, abarca más que la estructura de árbol: un nodo hijo en la estructura red puede tener más de un nodo padre. En otras palabras, la restricción de que en un árbol jerárquico cada hijo puede tener sólo un padre, se hace menos severa, y así, la estructura de árbol se puede considerar como un caso especial de la estructura de red. Modelo relacional: El modelo relacional, para el modelado y la gestión de bases de
datos, es un modelo de datos basado en la lógica de predicados y en la teoría de
conjuntos, siendo su idea fundamental el uso de relaciones. Estas relaciones podrían considerarse en forma lógica como conjuntos de datos llamados tuplas, 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"). Es el modelo más utilizado en la actualidad para modelar problemas reales y administrar datos dinámicamente. Ventajas: Provee
herramientas que garantizan evitar la duplicidad de registros;
Garantiza la integridad referencial, así, al eliminar un registro elimina todos los registros relacionados dependientes; Favorece la normalización por ser más comprensible y aplicable. Desventajas: Presentan deficiencias con datos gráficos, multimedia, CAD y sistemas
de información geográfica; No se manipulan de forma eficiente los bloques de texto como tipo de dato; Las bases de datos orientadas a objetos (BDOO) se propusieron con el objetivo de satisfacer las necesidades de las aplicaciones anteriores y así, complementar, pero no sustituir a las bases de datos relacionales. Descripción: 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 estos 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. Esquema:
Un esquema contiene 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 qué tipo de información podrá ser almacenada dentro de ella; en otras
palabras, el esqu esquema ema contiene con tiene 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, equivalente al tipo de d e dato por ejemplo character, integer, date, string... 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: Ciertos caracteres y números (una sola columna de una sola fila); Algunas o todas las filas con todas o algunas columnas; Cada fila es una tupla; El número de filas es llamado cardinalidad; El número de columnas es llamado aridad o grado.
Base de datos datos relacio relacional nal Una base de datos relacional es un conjunto de una o más tablas estructuradas en registros (líneas) y campos (columnas), que se vinculan entre sí por un campo en común, en ambos casos posee las mismas características como por ejemplo el nombre de campo, tipo y longitud; a este campo generalmente se le denomina ID, identificador o clave. A esta manera de construir bases de datos se le denomina modelo relacional. Estrictamente hablando el término se refiere a una colección específica de datos, pero a menudo se le usa, en forma errónea como sinónimo del software usado para gestionar esa colección de datos. Ese software se conoce como sistema gestor de base de datos relacional (SGBD) o en inglés relational database management system (RDBMS). Las bases de datos relacionales pasan por un proceso al que se le conoce como normalización de una base de datos, el cual es entendido como el proceso necesario para que una base de datos sea utilizada de manera óptima. Modelo entidad relación: Un modelo entidad-relación o diagrama entidad-relación (a veces – relación:
denominado por sus siglas en inglés, E-R Entity relationship; en español DER: "Diagrama de Entidad-Relación") es una herramienta para el modelado de d e datos que permite representar las entidades relevantes de un sistema de información, así como sus interrelaciones y propiedades. Ejemplo:
1. El Modelo Entidad-Relación Entidad-Relación Se elabora el diagrama (o diagramas) entidad-relación.
Se completa el modelo con listas de atributos y una descripción d escripción de otras restricciones
que no se pueden reflejar en el diagrama. El modelado de datos no acaba con el uso de esta técnica. Son necesarias otras técnicas para lograr un modelo directamente implementable en una base de datos, permitiendo: mostrar resultados entre otras entidades pertenecientes a las existentes de manera que se encuentre la normatividad de archivos que se almacenarán. Transformación de relaciones múltiples en binarias.
Normalización de una base de datos de relaciones (algunas relaciones pueden
transformarse en atributos y viceversa). Conversión en tablas (en caso de utilizar una base de datos relacional).
2. Base teóric teóricaa y concep conceptual tual
El modelo de datos entidad-relación 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 esos objetos. En donde: Entidad: r eepresenta presenta una “cosa”, "objeto" o "concepto" del mundo real con existencia
independiente, es decir, se diferencia únicamente de otro objeto o cosa, incluso siendo del mismo tipo, o una misma entidad. Algunos Ejemplos: Una persona. (Se diferencia de cualquier otra persona, incluso siendo gemelos).
Un automóvil. (Aunque sean de la misma marca, el mismo modelo,..., tendrán
atributos diferentes, por ejemplo, el número de chasis). Una casa (Aunque sea exactamente igual a otra, aún se diferenciará en su dirección).
Una entidad puede ser un objeto con existencia física como: una persona, un animal, una casa, etc. (entidad concreta); o un objeto con existencia conceptual como: un puesto de trabajo, una asignatura de clases, un nombre, etc. (entidad abstracta). Una entidad está descrita y se representa por sus características o atributos. Por ejemplo, la entidad Persona las características: Nombre, Apellido, Género, Estatura, Peso, Fecha de nacimiento. Atributos: Los atributos son las características que definen o identifican a una entidad. Estas
pueden ser muchas, y el diseñador solo utiliza o implementa implementa llas as que considere más relevantes. En un conjunto de entidades del mismo tipo, cada entidad tiene valores específicos asignados para cada uno de sus atributos, de d e esta forma, es posible su identificación unívoca. Ejemplos: A la colección de entidades «alumnos», con el siguiente conjunto de atributos en común, (id, nombre, edad, semestre), pertenecen las entidades: (1, Sophia, 15 años, 2); (2, Josefa, 19 años, 5); (3, Carlos, 20 años, 2) Cada una de las entidades pertenecientes a este conjunto se diferencia de las demás por el valor de sus atributos. Nótese que dos o más entidades diferentes pueden tener los mismos valores para algunos de sus atributos, pero nunca para todos. En particular, los atributos identificativos son aquellos que permiten diferenciar a una instancia de la entidad de otra distinta. Por ejemplo, el atributo identificativo que distingue a un alumno de otro es
su número de id. Para cada atributo, existe un dominio del mismo, este hace referencia refer encia al tipo de datos que será almacenado a restricciones en los valores que el atributo puede tomar (cadenas de caracteres, números, solo dos letras, solo números mayores que cero, solo números enteros...). De igual manera, cuando algún atributo correspondiente a una entidad no tiene un valor determinado, recibe el valor nulo, bien sea porque no se conoce, porque no existe o porque no se sabe nada al respecto del mismo. Conjunto de relaciones:
Consiste en una colección, o conjunto, de relaciones de la misma
naturaleza. Ejemplo: Dados los conjuntos de entidades "Habitación" y "Huésped", todas las relaciones de la forma habitación-huésped, permiten obtener la información de los huéspedes y sus respectivas habitaciones. La dependencia o asociación entre los conjuntos de entidades es llamada participación. En el ejemplo anterior los conjuntos de entidades "Habitación" y "Huésped" participan en el conjunto de relaciones habitación-huésped. Se llama grado del conjunto de relaciones a la cantidad de conjuntos de entidades participantes en la relación.
3. Restriccio Restricciones nes Son reglas que deben respetar las entidades y relaciones almacenadas en la base de datos. Correspondencia de cardinalidades: Dado un conjunto de relaciones en el que participan dos
o más conjuntos de entidades, la correspondencia de cardinalidad indica el número de entidades con las que puede estar relacionada una entidad dada. Dado un conjunto de relaciones binarias y los conjuntos de entidades A y B, la correspondencia de cardinalidades puede ser: Uno a Uno: (1:1). Un registro de una entidad A se relaciona con solo un registro en
una entidad B. (ejemplo dos entidades, profesor y departamento, depar tamento, con llaves primarias,
código_profesor y jefe_depto respectivamente, un profesor solo puede ser jefe de un departamento y un departamento solo puede tener un jefe). Uno a Varios: (1:N). Un registro en una entidad en A se relaciona con cero cer o o muchos
registros en una entidad B. Pero los registros de B solamente se relacionan con un registro en A. (ejemplo: dos entidades, vendedor y ventas, con llaves primarias, código_vendedor y venta, respectivamente, un vendedor puede tener muchas ventas pero una venta solo puede tener un vendedor). v endedor). Varios a Uno: (N:1). Una entidad en A se relaciona exclusivamente con una entidad
en B. Pero una entidad en B se puede relacionar con 0 o muchas entidades en A (ejemplo empleado-centro de trabajo). Varios a Varios: (N:M). Una entidad en A se puede relacionar con 0 o con muchas
entidades en B y viceversa (ejemplo asociaciones-ciudadanos, donde muchos ciudadanos pueden pertenecer a una misma asociación, y cada ciudadano puede pertenecer a muchas asociaciones distintas). distintas) . Restricciones de participación
Dado un conjunto de relaciones R en el cual participa un conjunto de entidades A, dicha participación puede ser de dos tipos: Total: Cuando cada entidad en A participa en al menos una relación de R.
Parcial: Cuando al menos una entidad en A NO participa en alguna relación de R.
4. Claves Es un subconjunto del conjunto de atributos comunes en una colección de entidades, que permite identificar inequívocamente cada una de las entidades pertenecientes a dicha colección. Asimismo, permiten distinguir entre sí las relaciones de un conjunto co njunto de relaciones. Dentro de los conjuntos de entidades existen los siguientes tipos de claves: Superclave: Es un subconjunto de atributos que permite distinguir unívocamente cada
una de las entidades de un conjunto de entidades. Si se añade un atributo al anterior subconjunto, el resultado seguirá siendo una superclave. Clave candidata: Se trata de superclave mínima, es decir, cualquier subconjunto de
atributos de la misma no puede ser una superclave.
Clave primaria: Es una clave candidata, elegida por el diseñador de la base de datos,
para identificar unívocamente las entidades en un conjunto de entidades.
5. Diagrama ent entidad-rela idad-relación ción Anteriormente detallamos los conceptos relacionados al modelo ER, en esta sección profundizaremos en como representarlos gráficamente. gráfi camente. Cabe destacar que para todo proceso de modelado, siempre hay que tener en claro los conceptos, estos nos brindan conocimiento necesario y además fundamentan nuestro modelo al momento de presentarlo a terceros. Formalmente, los diagramas ER son un lenguaje gráfico para describir conceptos. Informalmente, son simples dibujos o gráficos que describen información que trata un sistema de información y el software que lo automatiza. Ejemplo: Modelo entidad – relación relación extendido
Los diagramas Entidad-Relación no cumplen su propósito con eficacia debido a que tienen limitaciones semánticas. Por ese motivo se suelen utilizar los diagramas EntidadRelación extendidos que incorporan algunos elementos más al lenguaje: Entidades fuertes y débiles
Cuando una entidad participa en una relación puede adquirir un papel fuerte o débil. Una entidad débil es aquella que no puede existir sin participar en la relación; es decir, aquella que no puede ser unívocamente identificada solamente por sus atributos. Al contrario, una entidad fuerte (también conocida como entidad regular) es aquella que sí puede ser identificada unívocamente. En los casos en que se requiera, se puede dar que una entidad fuerte "preste" algunos de sus atributos a una entidad débil para que esta última se pueda identificar. Se puede hablar de la existencia de dos tipos de dependencias en las entidades débiles:
Dependencia por existencia: Las ocurrencias de la entidad débil pueden
identificarse mediante un atributo identificador clave sin necesidad de identificar la entidad fuerte relacionada.
Dependencia por identidad: La entidad débil no puede ser identificada sin la
entidad fuerte relacionada. (Ejemplo: si tenemos una entidad LIBRO y otra relacionada EDICIÓN, para identificar una edición necesitamos conocer el identificador del libro). Atributos en relaciones
Las relaciones también pueden tener atributos asociados. Se representan igual que los atributos de las entidades. Un ejemplo típico son las relaciones de tipo "histórico" donde debe constar una fecha o una hora. Por ejemplo, supongamos que es necesario hacer constar la fecha de emisión de una factura a un cliente, y que es posible emitir duplicados de la factura (con distinta fecha). En tal caso, el atributo "Fecha de emisión" emisió n" de la factura debería colocarse en la relación "se emite".
Herencia
La herencia es un intento de adaptación de estos diagramas al paradigma orientado a objetos. La herencia es un tipo de d e relación entre una entidad "padre "padre"" y una entidad "hijo". La entidad "hijo" hereda todos los atributos y relaciones de la entidad "padre". Por tanto, no necesitan ser representadas dos veces en el diagrama. La relación de herencia se representa mediante un triángulo invertido interconectado por líneas a las entidades. La entidad conectada por la parte superior del triángulo es la entidad "padre". Solamente puede existir una entidad "padre" (herencia simple). Las entidades "hijo" se conectan por la parte inferior del triángulo. Agregación
Es un tipo de relación dinámica, donde el tiempo de vida de una o más entidades de bajo nivel que están incluidas inc luidas en una entidad de alto nivel es independiente inde pendiente a la entidad que la incluye(entidad de alto nivel). Es decir, es una abstracción abstr acción a través de la cual las relaciones se tratan como entidades de un nivel más alto. Se utiliza para expresar relaciones entre relaciones o entre entidades y relaciones. Se representa englobando la relación abstraída y las entidades que participan en ella en un rectángulo. En la figura se muestra un ejemplo de agregación en el que se representa repr esenta la situación en la que un profesor profesor,, cuando está impartiendo
una clase, puede poner una incidencia ocurrida a lo largo de ésta (se fue la luz, falta la configuración de un determinado software, etc.). Base de datos orientada a objetos
En una base de datos orientada a objetos, la información se representa mediante objetos como los presentes en la programación orientada a objetos. Cuando se integra las características de una base de datos con las de un lenguaje de programación orientado a objetos, el resultado es un sistema gestor de base de datos orientada a objetos (ODBMS, object database management system). Un ODBMS hace que los objetos de la base de datos aparezcan como objetos de un lenguaje de programación en uno o más lenguajes de programación a los que dé soporte. Un ODBMS extiende los lenguajes con datos persistentes de forma transparente, control de concurrencia, recuperación de datos, consultas asociativas y otras capacidades. Por consiguiente, las bases de datos orientadas a objetos se diseñan para trabajar bien en conjunción con lenguajes de programación orientados a objetos como Java, C#, Visual Basic.NET y C++. Los ODBMS usan exactamente el mismo modelo que estos lenguajes de programación. Los ODBMS proporcionan los costes de desarrollo más bajos y el mejor rendimiento cuando se usan objetos gracias a que almacenan objetos en disco y tienen una integración transparente con el programa escrito en un lenguaje de programación orientado a objetos, al almacenar exactamente el modelo de objeto usado a nivel aplicativo, lo que reduce los costes de desarrollo y mantenimiento.
ABSTRACCIONES COMÚNMENTE COMÚNMENTE USADAS EN EL MODELAJE MODELAJE CONCEPTUAL La abstracción es un proceso mental que se aplica al seleccionar algunas características y propiedades de un conjunto de objetos y excluir otras no pertinentes. Por representar un ejemplo: El concepto de una bicicleta puede verse como un proceso de abstracción, en el que se han excluido los detalles de su estructura. Podemos destacar tres niveles principales según la visión y la función que realice el usuario sobre la base de datos:
Nivel físico: El nivel más bajo de abstracción describe como se almacenan realmente
los datos. En el nivel físico se describen en detalle las estructuras de datos complejas de bajo nivel. Nivel conceptual: Que es el siguiente nivel nivel más alto de abstracción, se describe cuáles
son los datos reales que están almacenados en la base de datos y qué relaciones existen entre los datos. Nivel lógico: El siguiente nivel más alto de abstracción describe que datos se
almacenan en la base de datos y que 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 físico, los usuarios del nivel lógico no necesitan preocuparse de esta complejidad. Los administradores de base de datos, que deben decidir la información que se mantiene en la base de datos, usan el nivel lógico de abstracción. Abstracciones y Requerimientos de Datos.
Independencia
de implementación: No modelar representación de datos,
organización interna, entre otros. Abstracción: Tomar solo aspectos principales (cosas que no cambien)
Formalidad: Sintaxis no ambigua, Rico en semántica
Constructibilidad: Debe facilitar facilitar la comunicación analista usuario
Fácil de analizar: Para detectar ambigüedad, inconsistencia, completitud
Trazabilidad: Habilidad para seguir los elementos del modelo Ejecutabilidad: Poder animar el modelo, para comparar con la realidad
Minimalidad: No redundancia de conceptos (cada cosa expresada de una forma)
DISEÑO DE BASES DE DATOS. DATOS. Proceso de Diseño
El proceso de diseño consta de los pasos siguientes: Determinar la finalidad de la base de datos.
Buscar y organizar la información necesaria: Reúna todos los tipos de información
que desee registrar en la base de datos, como los nombres de productos prod uctos o los números de pedidos. Dividir la información en tablas: Divida los elementos de información inf ormación en entidades o
temas principales, como Productos o Pedidos. Cada tema pasará a ser una tabla. Convertir los elementos de información en columnas: Decida qué información desea
almacenar en cada tabla. Cada elemento se convertirá en un campo y se mostrará como una columna en la tabla. Por ejemplo, una tabla Empleados podría incluir campos como Apellido y Fecha de contratación. Especificar claves principales: Elija
la clave principal de cada tabla. La clave principal
es una columna que se utiliza para identificar inequívocamente cada fila, como Id. de producto o Código de cliente. Definir relaciones entre las tablas: Examine cada tabla y decida cómo se relacionan los
datos de una tabla con las demás tablas. Agregue campos a las tablas o cree nuevas tablas para clarificar las según sea necesario. necesa rio. Ajustar el diseño: Analice
el diseño para detectar errores. Cree las tablas y agregue
algunos registros con datos de ejemplo. Compruebe si puede obtener los resultados previstos de las tablas. Realice los ajustes necesarios en el diseño. Aplicar las reglas de normalización: Aplique
reglas de normalización de los datos para
comprobar si las tablas están estructuradas correctamente. Realice los ajustes necesarios en las tablas.
UNIVERSO DE DISCURSO. Se define como una descripción abstracta y general de la parte o sector del universo real que el contenido de la base de datos va a representar. En este nivel de análisis se está tratando con una descripción de la realidad, no con datos, y suele contener listas de tipos de entidades, de las relaciones existentes entre esas entidades y de las restricciones de integridad
que se aplican sobre ellas. El esquema conceptual de la base de datos puede utilizarse para integrar los intereses de los diferentes usuarios, como herramienta de representación y de formación, así como para prever futuras modificaciones del sistema. En el aspecto de la representación, lo más interesante es utilizar algún tipo de especificación formal en sentido matemático, lo que facilita la consistencia y los análisis lógicos de los esquemas propuestos. propues tos. Del esquema conceptual formalizado pueden derivarse diferentes subes quemas conceptuales, que representan aquellas partes del esquema conceptual de interés para un usuario o grupo de usuarios finales.
View more...
Comments