El documento presenta un plan de estudios para una unidad temática sobre bases de datos. Cubre temas como los antecedentes históricos, conceptos generales, necesidad y justificación, ciclo de vida de un sistema de base de datos, modelos de bases de datos relacionales, diseño de bases de datos relacionales y lenguajes de bases de datos. Incluye cinco unidades temáticas con objetivos de aprendizaje y bibliografía sugerida.
Integridad Y Seguridad En Las Bases De DatosDrakonis11
La seguridad de los datos en una base de datos implica tres aspectos principales: 1) autenticación de usuarios a través de códigos de acceso, contraseñas u otros mecanismos; 2) autorización de acceso a datos según el perfil de cada usuario; y 3) uso de técnicas como cifrado para proteger los datos, especialmente en entornos distribuidos o de acceso remoto.
Este documento describe los fundamentos del desarrollo de software basado en componentes. Explica que un componente es una unidad de software reutilizable con interfaces definidas. El desarrollo basado en componentes permite construir sistemas mediante la combinación de componentes preexistentes, lo que reduce costos y mejora la calidad. Detalla las etapas como la selección, adaptación y ensamblaje de componentes, así como las características y beneficios de esta aproximación.
Este documento presenta 6 ejercicios de modelado entidad-relación. El primer ejercicio propone modelar los datos de un instituto incluyendo profesores, módulos impartidos y alumnos matriculados. El segundo ejercicio propone modelar los datos de una concesionaria de autos incluyendo coches, clientes y revisiones. El tercer ejercicio propone modelar los datos de una clínica incluyendo pacientes, médicos e ingresos hospitalarios. El cuarto ejercicio propone modelar una tienda de productos informáticos incluy
El documento presenta un cuadro sinóptico que compara tres modelos de datos: el modelo entidad-relación, el modelo relacional y el modelo UML. Para cada modelo, se indican sus ventajas como su precisión, normalización y herramientas, y sus desventajas como carecer de soporte formal, no manejar bien datos no estructurados y no determinar completamente los requisitos.
El documento describe los diferentes niveles de abstracción en el diseño de bases de datos: esquema conceptual, modelo conceptual, esquema lógico, esquema físico. Explica que el modelo entidad-relación es el modelo conceptual más utilizado y describe sus elementos básicos como entidades, relaciones, atributos y claves.
Este documento presenta varios diagramas UML como diagramas de clases, actividades y casos de uso para un sistema de consultorio médico. Los diagramas describen las clases principales como Paciente, Médico y Medicina, y las actividades como generar citas médicas, realizar diagnósticos y recetas. Los casos de uso muestran las interacciones entre actores como pacientes, médicos y secretarias para tareas como solicitar citas y consultas médicas.
Este documento explica los conceptos de normalización de bases de datos, incluyendo las diferentes formas normales (1FN a 5FN). Define conceptos como dependencia funcional, redundancia, anomalías y cómo dividir tablas problemáticas en tablas más normalizadas para eliminar estas anomalías.
El documento describe tres ejercicios para diseñar diagramas de clases. El primer ejercicio involucra una biblioteca con libros, autores, categorías, editoriales y copias. Los lectores pueden tener préstamos múltiples de libros con multas por retrasos. El segundo ejercicio es sobre una empresa de alquiler de autos con clientes, reservas de múltiples autos, y detalles como fechas y precios. El tercer ejercicio no proporciona detalles.
Integridad Y Seguridad En Las Bases De DatosDrakonis11
La seguridad de los datos en una base de datos implica tres aspectos principales: 1) autenticación de usuarios a través de códigos de acceso, contraseñas u otros mecanismos; 2) autorización de acceso a datos según el perfil de cada usuario; y 3) uso de técnicas como cifrado para proteger los datos, especialmente en entornos distribuidos o de acceso remoto.
Este documento describe los fundamentos del desarrollo de software basado en componentes. Explica que un componente es una unidad de software reutilizable con interfaces definidas. El desarrollo basado en componentes permite construir sistemas mediante la combinación de componentes preexistentes, lo que reduce costos y mejora la calidad. Detalla las etapas como la selección, adaptación y ensamblaje de componentes, así como las características y beneficios de esta aproximación.
Este documento presenta 6 ejercicios de modelado entidad-relación. El primer ejercicio propone modelar los datos de un instituto incluyendo profesores, módulos impartidos y alumnos matriculados. El segundo ejercicio propone modelar los datos de una concesionaria de autos incluyendo coches, clientes y revisiones. El tercer ejercicio propone modelar los datos de una clínica incluyendo pacientes, médicos e ingresos hospitalarios. El cuarto ejercicio propone modelar una tienda de productos informáticos incluy
El documento presenta un cuadro sinóptico que compara tres modelos de datos: el modelo entidad-relación, el modelo relacional y el modelo UML. Para cada modelo, se indican sus ventajas como su precisión, normalización y herramientas, y sus desventajas como carecer de soporte formal, no manejar bien datos no estructurados y no determinar completamente los requisitos.
El documento describe los diferentes niveles de abstracción en el diseño de bases de datos: esquema conceptual, modelo conceptual, esquema lógico, esquema físico. Explica que el modelo entidad-relación es el modelo conceptual más utilizado y describe sus elementos básicos como entidades, relaciones, atributos y claves.
Este documento presenta varios diagramas UML como diagramas de clases, actividades y casos de uso para un sistema de consultorio médico. Los diagramas describen las clases principales como Paciente, Médico y Medicina, y las actividades como generar citas médicas, realizar diagnósticos y recetas. Los casos de uso muestran las interacciones entre actores como pacientes, médicos y secretarias para tareas como solicitar citas y consultas médicas.
Este documento explica los conceptos de normalización de bases de datos, incluyendo las diferentes formas normales (1FN a 5FN). Define conceptos como dependencia funcional, redundancia, anomalías y cómo dividir tablas problemáticas en tablas más normalizadas para eliminar estas anomalías.
El documento describe tres ejercicios para diseñar diagramas de clases. El primer ejercicio involucra una biblioteca con libros, autores, categorías, editoriales y copias. Los lectores pueden tener préstamos múltiples de libros con multas por retrasos. El segundo ejercicio es sobre una empresa de alquiler de autos con clientes, reservas de múltiples autos, y detalles como fechas y precios. El tercer ejercicio no proporciona detalles.
Este documento presenta un resumen de diferentes tipos de diagramas en UML, incluyendo diagramas de clases, objetos, estados y casos de uso. Un diagrama de clases muestra las relaciones entre las clases de un sistema. Un diagrama de objetos representa una instancia específica de un diagrama de clases en un momento dado. Los diagramas de estado ilustran los estados por los que pasa un objeto y los eventos que pueden cambiar su estado.
Este documento presenta una introducción a la tecnología orientada a objetos. Explica que la TOO se basa en principios como la abstracción, encapsulamiento, modularidad, jerarquía y otros. También describe conceptos clave como objetos, clases, encapsulamiento, herencia y más. Finalmente, provee antecedentes históricos sobre el desarrollo de la TOO a través de los años.
Este documento presenta el diseño e implementación de un sistema de control de inventarios y facturación utilizando la tecnología RFID. En el capítulo 1 se introducen los antecedentes, situación actual, planteamiento del problema y su solución propuesta. Los capítulos 2 y 3 contienen el marco teórico y análisis, respectivamente, incluyendo conceptos de RFID, herramientas de software y modelado UML. El capítulo 4 describe el diseño, construcción y pruebas del sistema, mientras que el capítulo 5 presenta las conclusiones y
El documento describe diferentes modelos de bases de datos, incluyendo bases de datos jerárquicas, de red, transaccionales y relacionales. Las bases de datos jerárquicas organizan los datos como un árbol, mientras que las bases de datos de red permiten que un nodo tenga múltiples padres. Las bases de datos transaccionales se enfocan en procesar grandes volúmenes de datos a alta velocidad, mientras que las bases de datos relacionales usan tablas relacionadas y el lenguaje SQL para almacenar y recuperar datos
Este documento presenta información sobre procedimientos almacenados y disparadores (triggers) en SQL. Explica que los procedimientos almacenados son conjuntos de instrucciones SQL guardadas en la base de datos que pueden ser llamadas por aplicaciones, y que los triggers se ejecutan automáticamente cuando ocurren eventos de manipulación de datos como inserciones, actualizaciones o eliminaciones. También cubre la sintaxis para crear, ejecutar y modificar procedimientos almacenados y triggers, así como sus ventajas y desventajas.
Ventajas y desventajas de los modelos de bdIrene Lorza
Este documento presenta un cuadro comparativo de los modelos de bases de datos relacionales y orientados a objetos. Describe las ventajas de los modelos relacionales como su simplicidad, herramientas para evitar duplicidad y garantizar integridad. También describe las ventajas de los modelos orientados a objetos como su capacidad para manipular datos complejos y ampliar la base de datos. Finalmente, indica desventajas para ambos modelos como limitaciones para ciertos tipos de datos o problemas de rendimiento.
El documento presenta el diagrama E-R, diagrama relacional y diccionario de datos de una base de datos para una pizzería. Incluye tablas para empleados, clientes, pedidos, productos, proveedores y las relaciones entre ellas. También incluye el script SQL para crear la base de datos.
El documento explica cómo crear y utilizar vistas en una base de datos. Una vista es una tabla virtual que devuelve datos de una consulta guardada con un nombre, sin almacenar datos físicamente. Para crear una vista se usa la sentencia CREATE VIEW seguida del nombre de la vista y una consulta SELECT. Las vistas permiten mostrar una perspectiva parcial o reestructurada de los datos almacenados y se pueden eliminar con DROP VIEW.
1) La presentación describe la programación en 3 capas, que separa la capa de presentación, negocio y datos para mejorar el desarrollo y mantenimiento. 2) La capa de presentación maneja la interfaz de usuario, la capa de negocio contiene las reglas de negocio y se comunica con las otras capas, y la capa de datos almacena y recupera la información de la base de datos. 3) La arquitectura por capas permite distribuir el trabajo y cada capa está aislada de las demás mejorando la flexibilidad.
Los métodos estructurados son una forma sistemática de modelar sistemas existentes o por construir. Fueron desarrollados en los años 70 para el análisis y diseño de software y evolucionaron en las décadas siguientes para soportar el desarrollo orientado a objetos. Proporcionan marcos para el modelado detallado de sistemas y herramientas para la edición de modelos y generación de código y documentación.
Este documento presenta una introducción a las bases de datos. Explica brevemente la historia de las bases de datos y cómo evolucionaron desde los sistemas de archivos para superar problemas como la redundancia y la inflexibilidad. Define una base de datos como una colección de datos almacenados de manera permanente que pueden ser compartidos y usados por múltiples usuarios. Finalmente, describe las funciones clave de un sistema gestor de bases de datos, incluyendo el manejo de transacciones, control de acceso, recuperación ante fallas y mantenimiento de la integrid
El documento describe las bases de datos orientadas a objetos, incluyendo su concepto, historia y características. Estas bases de datos incorporan los conceptos de encapsulación, herencia y polimorfismo del modelo de objetos, y los datos se almacenan como objetos en lugar de tablas. Las características incluyen objetos, identificadores únicos y encapsulamiento.
Este documento describe conceptos fundamentales de bases de datos, incluyendo tipos de bases de datos como operativas, distribuidas y externas. También explica el procesamiento tradicional de archivos, el enfoque de administración de bases de datos y funciones de un sistema de administración de bases de datos como crear, mantener y utilizar bases de datos. Finalmente, cubre principios técnicos como estructuras de bases de datos relacionales, multidimensionales y orientadas a objetos.
El documento describe la evolución y clasificación de los modelos de bases de datos. Explica que los modelos conceptuales se enfocan en la representación lógica de los datos, mientras que los modelos de ejecución se enfocan en cómo los datos son representados físicamente. También describe los principales modelos como el jerárquico, de red, relacional y de entidad-relación, así como sus características básicas como entidades, atributos y relaciones.
Esta es una presentacion de la arquitectura 3 capas realizada con informacion recopilada de varios sitios web y de un trabajo elaborado por nosotras en la Universidad
Este documento presenta la historia de las bases de datos desde su nacimiento en la década de 1940 hasta la actualidad. Explica que las bases de datos surgieron para almacenar grandes cantidades de datos de forma electrónica y eficiente. Luego describe las cuatro generaciones de bases de datos y los sistemas comerciales más importantes, incluyendo las bases de datos jerárquicas, de red, relacionales y multidimensionales. Finalmente, resume algunos tipos y usos comunes de bases de datos.
Fundamentos básicos de la programación orientada a objetosALGLYS RAMIREZ
Este documento presenta los fundamentos básicos de la programación orientada a objetos (POO). Explica conceptos clave como objetos, clases, atributos, métodos, abstracción y encapsulamiento. También describe las relaciones jerárquicas y semánticas entre objetos y los objetos dinámicos.
Desarrollo de los temas que comprenden la unidad 1 de la materia Fundamentos de Bases de Datos en el Tecnológico de Estudios Superiores de Cuautitlán Izcalli en la carrera de Ingeniería en Sistemas Computacionales
video:
HISTORIA DE LAS BASES DE DATOS
http://www.youtube.com/watch?v=swg1dwTb7ek&feature=share&list=UUyes6KDoH--8_Nf4v2xFhkw
Este documento presenta un ejercicio para diseñar un modelo entidad-relación para la clínica "SAN PATRÁS" basado en el siguiente supuesto: la clínica desea llevar un control de sus pacientes, médicos e ingresos. Se requiere almacenar información como nombre, dirección y fecha de nacimiento para los pacientes, y nombre, especialidad y teléfono para los médicos. Cada ingreso de un paciente se registrará con un código único, habitación, fecha y el médico a cargo. Un médico puede atender varios ingres
El documento describe los requisitos para una base de datos que gestione la información de una cadena de agencias de viajes. La base de datos almacenará datos sobre sucursales, hoteles, vuelos, turistas y sus reservas. Las sucursales contratan a los turistas, los cuales pueden reservar vuelos y hoteles de la cadena. La base de datos rastreará estas reservas junto con la información maestra de sucursales, hoteles, vuelos y turistas.
El documento describe los diferentes modelos de bases de datos, incluyendo el modelo de red. El modelo de red fue desarrollado originalmente por Charles Bachman en 1969 y permitía una representación flexible de registros y su relación a través de enlaces. El modelo de red evita la redundancia al incorporar un tipo de registro conector para vincular otros registros.
Este documento habla sobre la vida eterna y cómo obtenerla. Brevemente resume que Jesús le explicó a Nicodemo que para entrar en el reino de Dios uno debe nacer de nuevo del Espíritu, no sólo físicamente. También cita versículos de 1 Juan que dicen que Dios nos ha dado vida eterna a través de su Hijo, y que aquel que cree en él tiene la vida, mientras que el que no cree no la tiene.
Este documento presenta un resumen de diferentes tipos de diagramas en UML, incluyendo diagramas de clases, objetos, estados y casos de uso. Un diagrama de clases muestra las relaciones entre las clases de un sistema. Un diagrama de objetos representa una instancia específica de un diagrama de clases en un momento dado. Los diagramas de estado ilustran los estados por los que pasa un objeto y los eventos que pueden cambiar su estado.
Este documento presenta una introducción a la tecnología orientada a objetos. Explica que la TOO se basa en principios como la abstracción, encapsulamiento, modularidad, jerarquía y otros. También describe conceptos clave como objetos, clases, encapsulamiento, herencia y más. Finalmente, provee antecedentes históricos sobre el desarrollo de la TOO a través de los años.
Este documento presenta el diseño e implementación de un sistema de control de inventarios y facturación utilizando la tecnología RFID. En el capítulo 1 se introducen los antecedentes, situación actual, planteamiento del problema y su solución propuesta. Los capítulos 2 y 3 contienen el marco teórico y análisis, respectivamente, incluyendo conceptos de RFID, herramientas de software y modelado UML. El capítulo 4 describe el diseño, construcción y pruebas del sistema, mientras que el capítulo 5 presenta las conclusiones y
El documento describe diferentes modelos de bases de datos, incluyendo bases de datos jerárquicas, de red, transaccionales y relacionales. Las bases de datos jerárquicas organizan los datos como un árbol, mientras que las bases de datos de red permiten que un nodo tenga múltiples padres. Las bases de datos transaccionales se enfocan en procesar grandes volúmenes de datos a alta velocidad, mientras que las bases de datos relacionales usan tablas relacionadas y el lenguaje SQL para almacenar y recuperar datos
Este documento presenta información sobre procedimientos almacenados y disparadores (triggers) en SQL. Explica que los procedimientos almacenados son conjuntos de instrucciones SQL guardadas en la base de datos que pueden ser llamadas por aplicaciones, y que los triggers se ejecutan automáticamente cuando ocurren eventos de manipulación de datos como inserciones, actualizaciones o eliminaciones. También cubre la sintaxis para crear, ejecutar y modificar procedimientos almacenados y triggers, así como sus ventajas y desventajas.
Ventajas y desventajas de los modelos de bdIrene Lorza
Este documento presenta un cuadro comparativo de los modelos de bases de datos relacionales y orientados a objetos. Describe las ventajas de los modelos relacionales como su simplicidad, herramientas para evitar duplicidad y garantizar integridad. También describe las ventajas de los modelos orientados a objetos como su capacidad para manipular datos complejos y ampliar la base de datos. Finalmente, indica desventajas para ambos modelos como limitaciones para ciertos tipos de datos o problemas de rendimiento.
El documento presenta el diagrama E-R, diagrama relacional y diccionario de datos de una base de datos para una pizzería. Incluye tablas para empleados, clientes, pedidos, productos, proveedores y las relaciones entre ellas. También incluye el script SQL para crear la base de datos.
El documento explica cómo crear y utilizar vistas en una base de datos. Una vista es una tabla virtual que devuelve datos de una consulta guardada con un nombre, sin almacenar datos físicamente. Para crear una vista se usa la sentencia CREATE VIEW seguida del nombre de la vista y una consulta SELECT. Las vistas permiten mostrar una perspectiva parcial o reestructurada de los datos almacenados y se pueden eliminar con DROP VIEW.
1) La presentación describe la programación en 3 capas, que separa la capa de presentación, negocio y datos para mejorar el desarrollo y mantenimiento. 2) La capa de presentación maneja la interfaz de usuario, la capa de negocio contiene las reglas de negocio y se comunica con las otras capas, y la capa de datos almacena y recupera la información de la base de datos. 3) La arquitectura por capas permite distribuir el trabajo y cada capa está aislada de las demás mejorando la flexibilidad.
Los métodos estructurados son una forma sistemática de modelar sistemas existentes o por construir. Fueron desarrollados en los años 70 para el análisis y diseño de software y evolucionaron en las décadas siguientes para soportar el desarrollo orientado a objetos. Proporcionan marcos para el modelado detallado de sistemas y herramientas para la edición de modelos y generación de código y documentación.
Este documento presenta una introducción a las bases de datos. Explica brevemente la historia de las bases de datos y cómo evolucionaron desde los sistemas de archivos para superar problemas como la redundancia y la inflexibilidad. Define una base de datos como una colección de datos almacenados de manera permanente que pueden ser compartidos y usados por múltiples usuarios. Finalmente, describe las funciones clave de un sistema gestor de bases de datos, incluyendo el manejo de transacciones, control de acceso, recuperación ante fallas y mantenimiento de la integrid
El documento describe las bases de datos orientadas a objetos, incluyendo su concepto, historia y características. Estas bases de datos incorporan los conceptos de encapsulación, herencia y polimorfismo del modelo de objetos, y los datos se almacenan como objetos en lugar de tablas. Las características incluyen objetos, identificadores únicos y encapsulamiento.
Este documento describe conceptos fundamentales de bases de datos, incluyendo tipos de bases de datos como operativas, distribuidas y externas. También explica el procesamiento tradicional de archivos, el enfoque de administración de bases de datos y funciones de un sistema de administración de bases de datos como crear, mantener y utilizar bases de datos. Finalmente, cubre principios técnicos como estructuras de bases de datos relacionales, multidimensionales y orientadas a objetos.
El documento describe la evolución y clasificación de los modelos de bases de datos. Explica que los modelos conceptuales se enfocan en la representación lógica de los datos, mientras que los modelos de ejecución se enfocan en cómo los datos son representados físicamente. También describe los principales modelos como el jerárquico, de red, relacional y de entidad-relación, así como sus características básicas como entidades, atributos y relaciones.
Esta es una presentacion de la arquitectura 3 capas realizada con informacion recopilada de varios sitios web y de un trabajo elaborado por nosotras en la Universidad
Este documento presenta la historia de las bases de datos desde su nacimiento en la década de 1940 hasta la actualidad. Explica que las bases de datos surgieron para almacenar grandes cantidades de datos de forma electrónica y eficiente. Luego describe las cuatro generaciones de bases de datos y los sistemas comerciales más importantes, incluyendo las bases de datos jerárquicas, de red, relacionales y multidimensionales. Finalmente, resume algunos tipos y usos comunes de bases de datos.
Fundamentos básicos de la programación orientada a objetosALGLYS RAMIREZ
Este documento presenta los fundamentos básicos de la programación orientada a objetos (POO). Explica conceptos clave como objetos, clases, atributos, métodos, abstracción y encapsulamiento. También describe las relaciones jerárquicas y semánticas entre objetos y los objetos dinámicos.
Desarrollo de los temas que comprenden la unidad 1 de la materia Fundamentos de Bases de Datos en el Tecnológico de Estudios Superiores de Cuautitlán Izcalli en la carrera de Ingeniería en Sistemas Computacionales
video:
HISTORIA DE LAS BASES DE DATOS
http://www.youtube.com/watch?v=swg1dwTb7ek&feature=share&list=UUyes6KDoH--8_Nf4v2xFhkw
Este documento presenta un ejercicio para diseñar un modelo entidad-relación para la clínica "SAN PATRÁS" basado en el siguiente supuesto: la clínica desea llevar un control de sus pacientes, médicos e ingresos. Se requiere almacenar información como nombre, dirección y fecha de nacimiento para los pacientes, y nombre, especialidad y teléfono para los médicos. Cada ingreso de un paciente se registrará con un código único, habitación, fecha y el médico a cargo. Un médico puede atender varios ingres
El documento describe los requisitos para una base de datos que gestione la información de una cadena de agencias de viajes. La base de datos almacenará datos sobre sucursales, hoteles, vuelos, turistas y sus reservas. Las sucursales contratan a los turistas, los cuales pueden reservar vuelos y hoteles de la cadena. La base de datos rastreará estas reservas junto con la información maestra de sucursales, hoteles, vuelos y turistas.
El documento describe los diferentes modelos de bases de datos, incluyendo el modelo de red. El modelo de red fue desarrollado originalmente por Charles Bachman en 1969 y permitía una representación flexible de registros y su relación a través de enlaces. El modelo de red evita la redundancia al incorporar un tipo de registro conector para vincular otros registros.
Este documento habla sobre la vida eterna y cómo obtenerla. Brevemente resume que Jesús le explicó a Nicodemo que para entrar en el reino de Dios uno debe nacer de nuevo del Espíritu, no sólo físicamente. También cita versículos de 1 Juan que dicen que Dios nos ha dado vida eterna a través de su Hijo, y que aquel que cree en él tiene la vida, mientras que el que no cree no la tiene.
SQL es un lenguaje de programación para trabajar con bases de datos relacionales como MySQL y Oracle. MySQL es un servidor de base de datos que permite crear, modificar y eliminar bases de datos y tablas, e insertar, consultar y ordenar datos. Se comunica con el servidor MySQL a través de instrucciones SQL introducidas en la línea de comandos o en un lenguaje como PHP.
Este documento introduce los conceptos básicos de las bases de datos. Explica que las bases de datos surgieron para integrar datos de diferentes sistemas y aplicaciones, eliminando la redundancia. Describe los tres modelos históricos de almacenamiento de datos: orientados a dispositivos, orientados a archivos y orientados a bases de datos. El modelo de base de datos centraliza los datos para su uso compartido y mantenimiento coherente.
El documento describe los conceptos básicos de las bases de datos, incluyendo su historia, tipos, componentes y modelos. Explica que una base de datos es un sistema para almacenar grandes cantidades de datos de forma organizada para su posterior recuperación y uso. Detalla los diferentes modelos de bases de datos como el relacional, jerárquico y de red, así como ejemplos de sistemas de gestión de bases de datos como MySQL, PostgreSQL y SQL Server.
El documento describe los sistemas jerárquicos y cómo modelarlos usando redes neuronales y sistemas borrosos. Explica los pasos para definir la estructura del modelo jerárquico, obtener datos de entrada-salida, adaptar parámetros usando retropropagación del error, y validar el modelo. Luego presenta un ejemplo de un sistema a modelar con varias plantas como entrada y cómo diseñar un modelo jerárquico de dos niveles para ello.
Un sistema transaccional es un sistema de información diseñado para recolectar, almacenar, modificar y recuperar información generada por transacciones en una organización. Un sistema transaccional debe controlar las transacciones para mantener la seguridad y consistencia de los datos involucrados y ser capaz de enmendar errores manteniendo los datos originales. Además, un sistema transaccional debe cumplir con las propiedades ACID para ser considerado transaccional.
El documento describe los conceptos fundamentales de una base de datos en red. Explica que una base de datos en red está formada por registros conectados entre sí mediante enlaces, permitiendo que un registro tenga múltiples padres. También describe los diagramas de estructura de datos que representan el diseño de una base de datos en red mediante celdas para los campos y líneas para los enlaces. Finalmente, explica algunas características clave del modelo de red Codasyl como los conjuntos que representan relaciones uno-a-muchos y las restricciones sobre
El documento describe los componentes y características del modelo de datos en red CODASYL. El modelo consta de una parte estática que define los objetos permitidos como registros, campos y conjuntos, y una parte dinámica que permite la navegación y actualización de registros. Las restricciones inherentes incluyen relaciones jerárquicas a dos niveles entre conjuntos de registros propietarios y miembros.
Comparacion software comercial vs libre (Gestores De Base De Datos)Oscar Ruiz Zapata
El documento habla sobre el software de gestión de bases de datos. Brevemente describe las ventajas e inconvenientes del software comercial frente al software libre. También compara dos sistemas de gestión de bases de datos populares, Oracle y PostgreSQL, destacando sus características.
Un modelo de datos es una representación abstracta de los objetos y eventos del mundo real y sus asociaciones. Existe un modelo conceptual que representa la vista lógica de los datos de forma independiente al sistema de gestión de base de datos, un modelo físico que describe cómo se almacenan los datos en la computadora, y varios tipos de modelos como los basados en objetos, registros y relacionales. El modelo conceptual es fundamental para dar soporte a las diferentes vistas de los datos.
Las bases de datos son conjuntos de datos almacenados sistemáticamente para su posterior uso. Una base de datos ofrece varias ventajas sobre los sistemas de archivos tradicionales, incluyendo la independencia lógica y física de los datos, la redundancia mínima, el acceso concurrente y la integridad de los datos. Los sistemas gestores de bases de datos (SGBD) actúan como interfaz entre la base de datos, los usuarios y las aplicaciones, permitiendo definir, acceder y manipular los datos de forma eficiente y segura.
Este documento describe las características y generalidades de Microsoft SQL Server. Explica que SQL Server es un sistema de gestión de bases de datos relacionales producido por Microsoft que permite almacenar y consultar datos de forma segura e integra mediante mecanismos como bloqueos, concurrencia optimista y recuperación flexible. También resalta las ventajas actuales de SQL Server como su capacidad en la nube y mantener los datos organizados y accesibles de manera rentable.
Una base de datos es una colección estructurada de datos compartidos que se almacenan de forma centralizada. Los modelos de datos como el entidad-relación son herramientas para representar la estructura y relaciones de los datos del mundo real. Los sistemas de gestión de bases de datos proporcionan lenguajes y herramientas para definir, consultar y administrar las bases de datos de forma eficiente e independiente de las aplicaciones.
El documento describe las diferentes fases del ciclo de vida de un sistema de información y de una base de datos, incluyendo el análisis de requisitos, diseño conceptual, diseño lógico, diseño físico e instalación y mantenimiento. También explica los modelos de ciclo de vida como el modelo en cascada y en espiral, y los pasos involucrados en el proceso de diseño de bases de datos.
El documento define un Sistema de Gestión de Bases de Datos (SGBD) y describe sus principales funciones, que incluyen el almacenamiento, modificación y extracción de datos de una base de datos, así como el mantenimiento de esquemas y la gestión de transacciones. También explica las características de los datos almacenados en una base de datos, como la independencia de datos y la reducción de redundancia, y clasifica los sistemas de bases de datos según su función y modelo de administración de datos.
El documento describe las funciones principales de un administrador de bases de datos (DBA), incluyendo definir el esquema conceptual y de almacenamiento, vincularse con los usuarios, definir seguridad e integridad, y procedimientos de respaldo. También describe los tipos principales de bases de datos, como jerárquicas, de red y relacionales. El modelo relacional es el más común hoy en día debido a su flexibilidad y facilidad de uso.
Este documento presenta información sobre bases de datos, incluyendo referencias bibliográficas. Explica conceptos clave como sistemas gestores de bases de datos, actores, ventajas y estructura global. También describe las diferentes formas de evaluación de un curso sobre bases de datos, incluyendo asistencia, participación, trabajos en equipo y un proyecto final.
Este documento presenta información sobre bases de datos. Incluye una introducción al tema y define conceptos clave como base de datos, sistema gestor de base de datos y sus funciones. También describe los actores principales en un sistema gestor de base de datos como el administrador, usuarios y lenguajes. Finalmente, incluye una bibliografía de libros y manuales sobre diferentes tecnologías y herramientas de bases de datos como DBase, FoxPro y Microsoft Access.
El documento explica los conceptos de independencia de datos, los tres niveles de la arquitectura ANSI-SPARC (nivel externo, conceptual e interno), los principales tipos de modelos de datos (incluyendo el modelo relacional y jerárquico), la función del modelo conceptual para representar los requisitos de datos de una organización, y la importancia del catálogo del sistema para almacenar información sobre los elementos de datos de forma centralizada.
El documento describe las funciones del administrador de bases de datos (DBA) y los tipos de bases de datos. Entre las funciones del DBA se encuentran definir los esquemas conceptual y interno de la base de datos, vincularse con los usuarios, definir medidas de seguridad e integridad, y supervisar el desempeño. Los tipos de bases de datos incluyen estáticas, dinámicas, bibliográficas, numéricas, jerárquicas, de red, relacionales, multidimensionales y orientadas a objetos.
Ciclo de vida de un sistema de informacionSergio, Chávez
El documento describe las etapas del ciclo de vida de un sistema de información, incluyendo el análisis, diseño, implementación, pruebas e instalación/despliegue. Luego se enfoca en las fases del proceso de diseño de bases de datos, que comprende el análisis de requerimientos, diseño conceptual, elección del SGBD, diseño lógico, diseño físico e instalación/mantenimiento. Cada fase tiene objetivos, tareas y resultados específicos para el diseño efectivo de la estructura y
El documento describe las 11 etapas del ciclo de vida de una base de datos, incluyendo la planificación, definición del sistema, recolección de requisitos, diseño de la base de datos, selección del SGBD, diseño de aplicaciones, prototipado, implementación, carga de datos, pruebas y mantenimiento. También explica las funciones clave de un administrador de base de datos como la administración de la estructura, actividad y sistema de la base de datos, así como asegurar la integridad, seguridad y disponibilidad de los datos
Este documento describe los componentes básicos de una base de datos, incluida su estructura, modelo relacional de datos, submodelo de datos y esquema de almacenamiento. También explica la diferencia entre una base de datos y un sistema de gestión de base de datos, y las operaciones básicas como selección, unión y diferencia que se pueden realizar en una base de datos relacional. Por último, proporciona ejemplos de objetos comunes en Access como tablas, consultas y formularios.
Este documento presenta una introducción a la tecnología de bases de datos. Explica que el objetivo de la materia es analizar los motores de bases de datos líderes en el mercado, incluyendo su arquitectura interna, seguridad e integración de datos. También define qué es una base de datos, sus componentes y niveles lógicos y físicos, y cómo surgió la necesidad de los sistemas de bases de datos para resolver problemas en los primeros sistemas de procesamiento de archivos.
Instituto distrital evardo turizo palenciaLeidyOsorioM
El documento presenta preguntas y respuestas sobre conceptos básicos de bases de datos. Explica que una base de datos es un conjunto de datos almacenados sistemáticamente para su posterior uso, y que los sistemas gestores de bases de datos (SGBD) permiten almacenar y acceder a los datos de forma rápida y estructurada. También describe los diferentes modelos de bases de datos como jerárquicos, de red, relacionales y orientados a objetos, así como los componentes de un sistema de base de datos.
Este documento provee una introducción a las bases de datos, incluyendo su definición, características, tipos, usuarios y arquitectura. Explica que una base de datos es un conjunto de datos almacenados sistemáticamente para su uso posterior, y que actualmente la mayoría son digitales. Describe los componentes clave de una base de datos relacional y las ventajas y desventajas de usar un sistema de base de datos.
El documento describe tres características clave de las bases de datos: la separación de datos y programas, el manejo de múltiples vistas de usuario, y el uso de un catálogo para almacenar la descripción de los datos. También describe la arquitectura de tres capas para separar las aplicaciones de usuario de la base de datos física, e incluye esquemas a nivel interno, conceptual y de vistas. Finalmente, resume brevemente los modelos de bases de datos transaccionales y relacionales.
Base de datos ciclo 1 - capítulo 1 - ok (1)Odali Suarez A
Este documento presenta información sobre la evaluación de una materia de bases de datos. Incluye una bibliografía recomendada, detalles sobre la evaluación que consiste en exámenes, lecciones, deberes, participación en clase y un proyecto. También presenta los objetivos generales del curso y un resumen de la primera unidad sobre introducción al manejo de datos.
Sistemas de gestión de bases de datos parte iiRicardo Rocha
Este documento describe la arquitectura de bases de datos, incluyendo los modelos de bases de datos, el modelo relacional y el SGBDR SQL Server 2008. Explica que la arquitectura de bases de datos tiene tres capas (interna, conceptual y externa) y que el modelo relacional organiza los datos en tablas. También resume las características de SQL Server como un potente SGBDR que admite transacciones, procedimientos almacenados y administración gráfica.
Esta presentación nos muestra los conceptos Fundamentales para el Diseño y Creación de Base de Datos Relacionales, se Centra en el Modelo de Datos Relacional, ya que es el mas usado a nivel mundial.
El documento describe el ciclo de vida de un sistema de información y el proceso de diseño de bases de datos. El ciclo de vida incluye etapas como la planificación, el análisis, el diseño, la implementación, las pruebas e instalación y el mantenimiento. El proceso de diseño de bases de datos consta de 6 fases: análisis de requerimientos, diseño conceptual, elección del SGBD, diseño lógico, diseño físico e instalación y mantenimiento.
Este documento describe las etapas clave del diseño de bases de datos, incluyendo el diseño conceptual, lógico y físico. Explica que el diseño conceptual utiliza el modelo entidad-relación para definir las entidades, relaciones, restricciones e integridad de los datos. El diseño lógico transforma este modelo en tablas relacionales y normaliza los esquemas. Finalmente, el diseño físico organiza los datos físicamente en el sistema de gestión de bases de datos.
30. MANEJADOR DE BASE DE DATOS E s la porción más importante del software de un sistema de base de datos.
31. VENTAJAS Proveen facilidades para la manipulación de grandes volúmenes de datos. Usualmente, proveen interfaces y lenguajes de consulta que simplifican la recuperación de los datos DESVENTAJAS Coste Complejidad Tamaño
34. Para introducirnos en este tema, empezaremos definiendo que es un modelo. Modelo: Es una representación de la realidad que contiene las características generales de algo que se va a realizar. En base de datos, esta representación la elaboramos de forma gráfica.
35. ¿Qué es modelo de datos? Una de las características fundamentales de los sistemas de bases de datos es que proporcionan cierto nivel de abstracción de datos, al ocultar las características sobre el almacenamiento físico que la mayoría de usuarios no necesita conocer. Los modelos de datos son el instrumento principal para ofrecer dicha abstracción. Un modelo de datos es un conjunto de conceptos que sirven para describir la estructura de una base de datos: los datos, las relaciones entre los datos y las restricciones que deben cumplirse sobre los datos. Los modelos de datos contienen también un conjunto de operaciones básicas para la realización de consultas (lecturas) y actualizaciones de datos. Además, los modelos de datos más modernos incluyen conceptos para especificar comportamiento, permitiendo especificar un conjunto de operaciones definidas por el usuario. Los modelos de datos se pueden clasificar dependiendo de los tipos de conceptos que ofrecen para describir la estructura de la base de datos.
36. MODELO CONCEPTUAL Los modelos de datos de alto nivel, o modelos conceptuales , disponen de conceptos muy cercanos al modo en que la mayoría de los usuarios percibe los datos. Se usan para describir datos en los niveles conceptual y de visión, es decir, con este modelo representamos los datos de tal forma como nosotros los captamos en el mundo real, tienen una capacidad de estructuración bastante flexible y permiten especificar restricciones de datos explícitamente. Los modelos conceptuales utilizan conceptos como entidades, atributos y relaciones. Una entidad representa un objeto o concepto del mundo real como, por ejemplo, un empleado de la empresa inmobiliaria o una oficina. Un atributo representa alguna propiedad de interés de una entidad como, por ejemplo, el nombre o el salario del empleado. Una relación describe una interacción entre dos o más entidades, por ejemplo, la relación de trabajo entre un empleado y su oficina.
37. Existen diferentes modelos de este tipo, pero el más utilizado por su sencillez y eficiencia es el modelo Entidad-Relación . Los modelos conceptuales deben ser buenas herramientas para representar la realidad, por lo que deben poseer las siguientes cualidades: Expresividad : deben tener suficientes conceptos para expresar perfectamente la realidad. Simplicidad : deben ser simples para que los esquemas sean fáciles de entender. Minimalidad : cada concepto debe tener un significado distinto. Formalidad : todos los conceptos deben tener una interpretación única, precisa y bien definida.
38. Se trata de obtener el esquema conceptual de la base de datos a partir de la lista descriptiva de objetos y asociaciones identificadas en la organización durante el análisis. Se recomienda realizar esta Modelización en varias etapas. Luego de cada etapa se realiza una "depuración" de la etapa precedente. Todas las etapas se apoyan sobre el mismo modelo: el modelo relacional introducido en el universo de la estructuración de datos. Esquemáticamente, el proceso de Conceptualización lleva a elaborar varias colecciones de esquemas de relaciones que deben traducirse de la manera mas sintética incluyendo la representación de los objetos y asociaciones que constituyen la realidad organizacional. MODELO CONCEPTUAL
39. El modelo entidad-relación es el modelo conceptual más utilizado para el diseño conceptual de bases de datos. Es una herramienta para el modelado de datos de un sistema de información. Expresa entidades relevantes para un sistema de información, sus inter-relaciones y propiedades. Fue introducido por Peter Chen en 1976. Sus siglas: E-R "Entity relationship", ó "DER" Diagrama de Entidad Relación MODELO ENTIDAD-RELACIÓN
40. Utiliza diagramas entidad relación. Consiste en los siguientes pasos: 1.-Se parte de una descripción textual del problema o sistema de información a automatizar (los requisitos). 2.-Se hace una lista de los sustantivos y verbos que aparecen. 3.-Los sustantivos son posibles entidades o atributos. 4.-Los verbos son posibles relaciones. 5.-Analizando las frases se determina la cardinalidad de las relaciones y otros detalles. 6.-Se elabora el diagrama (o diagramas) entidad-relación. 7.-Se completa el modelo con listas de atributos y una descripción de otras restricciones que no se pueden reflejar en el diagrama. Se caracteriza por utilizar una serie de símbolos y reglas para representar los datos y sus relaciones. Representa de manera grafica la estructura lógica de una base de datos.
41. Entidad: Cualquier tipo de objeto o concepto sobre el que se recoge información: cosa, persona, concepto abstracto o suceso. Ejemplo: coches, casas, empleados, etc. Se representan gráficamente mediante rectángulos y su nombre aparece en el interior. Un nombre de entidad sólo puede aparecer una vez en el esquema conceptual. Relación (interrelación) :Es una correspondencia o asociación entre dos o más entidades. Cada relación tiene un nombre que describe su función. Las relaciones se representan gráficamente mediante rombos y su nombre aparece en el interior.
42. Atributo Es una característica de interés o un hecho sobre una entidad o sobre una relación. Los atributos representan las propiedades básicas de las entidades y de las relaciones. Gráficamente, se representan mediante bolitas que cuelgan de las entidades o relaciones a las que pertenecen.
43.
44.
45. Identificador Un identificador de una entidad es un atributo o conjunto de atributos que determina de modo único cada ocurrencia de esa entidad. Un identificador de una entidad debe cumplir dos condiciones: No pueden existir dos ocurrencias de la entidad con el mismo valor del identificador. Si se omite cualquier atributo del identificador, la condición anterior deja de cumplirse. Toda entidad tiene al menos un identificador y puede tener varios identificadores alternativos. Las relaciones no tienen identificadores.
46. Ejemplo de dos entidades con sus atributos, relacionadas entre si
47. GENERALIDADES DE CONSTRUCCIÓN El primer paso en el diseño de una base de datos es la producción del esquema conceptual. Normalmente, se construyen varios esquemas conceptuales, cada uno para representar las distintas visiones que los usuarios tienen de la información. Cada una de estas visiones suelen corresponder a las diferentes áreas funcionales de la empresa como, por ejemplo, producción, ventas, recursos humanos, etc. Estas visiones de la información, denominadas vistas , se pueden identificar de varias formas. Una opción consiste en examinar los diagramas de flujo de datos, que se pueden haber producido previamente, para identificar cada una de las áreas funcionales. La otra opción consiste en entrevistar a los usuarios, examinar los procedimientos, los informes y los formularios, y también observar el funcionamiento de la empresa.
48.
49. 1. Identificar las entidades En primer lugar hay que definir los principales objetos que interesan al usuario. Estos objetos serán las entidades. Una forma de identificar las entidades es examinar las especificaciones de requisitos de usuario. En estas especificaciones se buscan los nombres o los sintagmas nominales que se mencionan (por ejemplo: número de empleado, nombre de empleado, número de inmueble, dirección del inmueble, alquiler, número de habitaciones). También se buscan objetos importantes como personas, lugares o conceptos de interés, excluyendo aquellos nombres que sólo son propiedades de otros objetos. Por ejemplo, se pueden agrupar el número de empleado y el nombre de empleado en una entidad denominada empleado , y agrupar número de inmueble, dirección del inmueble, alquiler y número de habitaciones en otra entidad denominada inmueble .
50. Otra forma de identificar las entidades es buscar aquellos objetos que existen por sí mismos. Por ejemplo, empleado es una entidad porque los empleados existen, sepamos o no sus nombres, direcciones y teléfonos. Siempre que sea posible, el usuario debe colaborar en la identificación de las entidades. Conforme se van identificando las entidades, se les dan nombres que tengan un significado y que sean obvias para el usuario. Los nombres de las entidades y sus descripciones se anotan en el diccionario de datos. Cuando sea posible, se debe anotar también el número aproximado de ocurrencias de cada entidad. Si una entidad se conoce por varios nombres, éstos se deben anotar en el diccionario de datos como alias o sinónimos.
51. 2. Identificar las relaciones Una vez definidas las entidades, se deben definir las relaciones existentes entre ellas. Del mismo modo que para identificar las entidades se buscaban nombres en las especificaciones de requisitos, para identificar las relaciones se suelen buscar las expresiones verbales (por ejemplo: oficina tiene empleados, empleado gestiona inmueble, cliente visita inmueble). Si las especificaciones de requisitos reflejan estas relaciones es porque son importantes para la empresa y, por lo tanto, se deben reflejar en el esquema conceptual. Pero sólo interesan las relaciones que son necesarias. En el ejemplo anterior, se han identificado las relaciones empleado gestiona inmueble y cliente visita inmueble . Se podría pensar en incluir una relación entre empleado y cliente: empleado atiende a cliente , pero observando las especificaciones de requisitos no parece que haya interés en modelar tal relación. La mayoría de las relaciones son binarias (entre dos entidades), pero no hay que olvidar que también puede haber relaciones en las que participen más de dos entidades, así como relaciones recursivas.
52. 3. Identificar los atributos y asociarlos a entidades y relaciones Al igual que con las entidades, se buscan nombres en las especificaciones de requisitos. Son atributos los nombres que identifican propiedades, cualidades, identificadores o características de entidades o relaciones. Lo más sencillo es preguntarse, para cada entidad y cada relación, ¿qué información se quiere saber de ...? La respuesta a esta pregunta se debe encontrar en las especificaciones de requisitos. Pero, en ocasiones, será necesario preguntar a los usuarios para que aclaren los requisitos. Desgraciadamente, los usuarios pueden dar respuestas a esta pregunta que también contengan otros conceptos, por lo que hay que considerar sus respuestas con mucho cuidado. Al identificar los atributos, hay que tener en cuenta si son simples o compuestos.
53. Por ejemplo, el atributo dirección puede ser simple, teniendo la dirección completa como un solo valor: `San Rafael 45, Almazora'; o puede ser un atributo compuesto, formado por la calle (`San Rafael'), el número (`45') y la población (`Almazora'). El escoger entre atributo simple o compuesto depende de los requisitos del usuario. Si el usuario no necesita acceder a cada uno de los componentes de la dirección por separado, se puede representar como un atributo simple. Pero si el usuario quiere acceder a los componentes de forma individual, entonces se debe representar como un atributo compuesto.
54. 4. Determinar los dominios de los atributos El dominio de un atributo es el conjunto de valores que puede tomar el atributo. Por ejemplo el dominio de los números de oficina son las tiras de hasta tres caracteres en donde el primero es una letra y el siguiente o los dos siguientes son dígitos en el rango de 1 a 99; el dominio de los números de teléfono y los números de fax son las tiras de 9 dígitos. Un esquema conceptual está completo si incluye los dominios de cada atributo: los valores permitidos para cada atributo, su tamaño y su formato. También se puede incluir información adicional sobre los dominios como, por ejemplo, las operaciones que se pueden realizar sobre cada atributo, qué atributos pueden compararse entre sí o qué atributos pueden combinarse con otros. Aunque sería muy interesante que el sistema final respetara todas estas indicaciones sobre los dominios, esto es todavía una línea abierta de investigación. Toda la información sobre los dominios se debe anotar también en el diccionario de datos.
55. 5. Determinar los identificadores Cada entidad tiene al menos un identificador. En este paso, se trata de encontrar todos los identificadores de cada una de las entidades. Los identificadores pueden ser simples o compuestos. De cada entidad se escogerá uno de los identificadores como clave primaria en la fase del diseño lógico. Cuando se determinan los identificadores es fácil darse cuenta de si una entidad es fuerte o débil. Si una entidad tiene al menos un identificador, es fuerte (otras denominaciones son padre , propietaria o dominante ). Si una entidad no tiene atributos que le sirvan de identificador, es débil (otras denominaciones son hijo , dependiente o subordinada ). Todos los identificadores de las entidades se deben anotar en el diccionario de datos.
56. 6. Determinar las jerarquías de generalización En este paso hay que observar las entidades que se han identificado hasta el momento. Hay que ver si es necesario reflejar las diferencias entre distintas ocurrencias de una entidad, con lo que surgirán nuevas subentidades de esta entidad genérica; o bien, si hay entidades que tienen características en común y que realmente son subentidades de una nueva entidad genérica. En cada jerarquía hay que determinar si es total o parcial y exclusiva o superpuesta.
57. 7. Dibujar el diagrama entidad-relación Una vez identificados todos los conceptos, se puede dibujar el diagrama entidad-relación correspondiente a una de las vistas de los usuarios. Se obtiene así un esquema conceptual local.
58. 8. Revisar el esquema conceptual local con el usuario Antes de dar por finalizada la fase del diseño conceptual, se debe revisar el esquema conceptual local con el usuario. Este esquema está formado por el diagrama entidad-relación y toda la documentación que describe el esquema. Si se encuentra alguna anomalía, hay que corregirla haciendo los cambios oportunos, por lo que posiblemente haya que repetir alguno de los pasos anteriores. Este proceso debe repetirse hasta que se esté seguro de que el esquema conceptual es una fiel representación de la parte de la empresa que se está tratando de modelar.
59. MODELO LOGICO El modelo lógico se usa en el UML para modelar los elementos estructurales estáticos. Captura y define los objetos, entidades y bloques de construcción de un sistema. Las clases son los moldes genéricos a partir de los que se crean los objetos en tiempo de ejecución del sistema. Los componentes (se discuten en "El modelo de componentes") se construyen a partir de las clases. Las clases (y las interfaces) son los elementos de diseño que corresponden a los artefactos de software codificados o desarrollados. Este artículo describirá algunas características del modelo de clases, cubrirá la notación del UML para describir las clases/objetos y dará un ejemplo del uso de la notación.
60. IDENTIFICACIÓN DE ATRIBUTOS Y ENTIDADES En nuestro esquema conceptual debemos incluir únicamente aquellos atributos que aparezcan referenciados en la especificación (lista de requerimientos funcionales, casos de uso y documentos adicionales) y, además, sean estrictamente necesarios para dar soporte a la funcionalidad de nuestro sistema. Los atributos puede que no se incluyan explícitamente en el diagrama asociado al esquema conceptual de una base de datos (para facilitar su interpretación cuando éste es complejo) pero SIEMPRE deberán aparecer en el diccionario de datos asociado al diagrama. En el esquema conceptual se pueden incluir atributos derivados (que, en UML, se marcan con el prefijo /), si bien éstos no se almacenarán físicamente en la base de datos (salvo que nos encontremos con problemas de rendimiento al llegar a la etapa de diseño físico). Es importante identificar el dominio de los atributos (el conjunto de valores permitido para cada atributo), así como indicar si el atributo puede tomar un valor nulo o no. Así mismo, cualquier restricción reseñable deberá figurar en el diccionario de datos asociado al modelo conceptual de nuestra base de datos: claves primarias y alternativas, relaciones entre atributos …
61. BASE DE DATOS RELACIONAL Éste es el modelo utilizado en la actualidad para modelar problemas reales y administrar datos dinámicamente. Tras ser postulados sus fundamentos 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 (las filas de una tabla), que representarían las tuplas, y campos (las columnas de una tabla). En este modelo, el lugar y la forma en que se almacenen los datos no tienen 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 para un usuario esporádico de la base de datos. La información puede ser recuperada o almacenada mediante "consultas" que ofrecen una amplia flexibilidad y poder para administrar la información. El lenguaje más habitual para construir las consultas a bases de datos relacionales es SQL, Structured Query Language o Lenguaje Estructurado de Consultas , un estándar implementado por los principales motores o sistemas de gestión de bases de datos relacionales. Durante su diseño, una base de datos relacional pasa por un proceso al que se le conoce como normalización de una base de datos.Durante los años '80 (1980-1989) la aparición de dBASE produjo una revolución en los lenguajes de programación y sistemas de administración de datos. Aunque nunca debe olvidarse que dBase no utilizaba SQL como lenguaje base para su gestión.
62. BASE DE DATOS JERARQUICO Éstas son bases de datos que, como su nombre indica, almacenan su información en una estructura jerárquica. En este modelo los datos se organizan en una forma similar a un árbol (visto al revés), en donde un nodo padre de información puede tener varios hijos . El nodo que no tiene padres es llamado raíz , y a los nodos que no tienen hijos se los conoce como hojas . Las bases de datos jerárquicas son especialmente útiles en el caso de aplicaciones que manejan un gran volumen de información y datos muy compartidos permitiendo crear estructuras estables y de gran rendimiento. Una de las principales limitaciones de este modelo es su incapacidad de representar eficientemente la redundancia de datos.
63. BASE DE DATOS DE RED Éste es un modelo ligeramente distinto del jerárquico; su diferencia fundamental es la modificación del concepto de nodo : se permite que un mismo nodo tenga varios padres (posibilidad no permitida en el modelo jerárquico). Fue una gran mejora con respecto al modelo jerárquico, ya que ofrecía una solución eficiente al problema de redundancia de datos; pero, aun así, la dificultad que significa administrar la información en una base de datos de red ha significado que sea un modelo utilizado en su mayoría por programadores más que por usuarios finales.
64. BASE DE DATOS ORIENTADO A OBJETOS Este modelo, bastante reciente, y propio de los modelos informáticos orientados a objetos, trata de almacenar en la base de datos los objetos completos (estado y comportamiento). Una base de datos orientada a objetos es una base de datos que incorpora todos los conceptos importantes del paradigma de objetos: Encapsulación - Propiedad que permite ocultar la información al resto de los objetos, impidiendo así accesos incorrectos o conflictos. Herencia - Propiedad a través de la cual los objetos heredan comportamiento dentro de una jerarquía de clases. Polimorfismo - Propiedad de una operación mediante la cual puede ser aplicada a distintos tipos de objetos. En bases de datos orientadas a objetos, los usuarios pueden definir operaciones sobre los datos como parte de la definición de la base de datos. Una operación (llamada función) se especifica en dos partes. La interfaz (o signatura) de una operación incluye el nombre de la operación y los tipos de datos de sus argumentos (o parámetros). La implementación (o método) de la operación se especifica separadamente y puede modificarse sin afectar la interfaz. Los programas de aplicación de los usuarios pueden operar sobre los datos invocando a dichas operaciones a través de sus nombres y argumentos, sea cual sea la forma en la que se han implementado. Esto podría denominarse independencia entre programas y operaciones. SQL:2003, es el estándar de SQL92 ampliado, soporta los conceptos orientados a objetos y mantiene la compatibilidad con SQL92.
67. Objetivos Disminuir los tiempos de respuesta. Minimizar espacio de almacenamiento. Evitar las reorganizaciones. Proporcionar la máxima seguridad. Optimizar el consumo de recursos.
68. VENTAJAS • Sirven para encontrar más rápido aquello que buscamos, por lo tanto y extrapolando a bases de datos podemos decir que nos sirven para agilizar las consultas a las tablas. • Evitamos un "escaneo completo de la tabla" lo que hace que cuando tenemos grandes cantidades de datos en nuestras tablas, la mejora puede ser muy importante.
69. ELEMENTOS Aunque no todos los sistemas comerciales disponen de ellos, y si existen el diseñador tiene la posibilidad de actuar sobre ellos ajustándolos a cada caso concreto, algunos de ellos se muestran a continuación: * Registros físicos. * Punteros. * Direccionamiento calculado (Hashing). * Agrupamientos (cluster). * Bloqueo y comprensión de datos. * Asignación de espacios de almacenamientos como memorias intermedias (buffers). * Asignación de conjuntos de datos a particiones y a dispositivos físicos.
70.
71.
72. UNIDAD III Modelo de base de datos red, jerárquica y orientada a objetos.
73. Modelo de red o reticular En el modelo relacional, los datos y las relaciones entre ellos se representan mediante un conjunto de tablas. El modelo de red se diferencia del modelo relacional en que los datos se representan mediante conjuntos de registros, y las relaciones entre ellos mediante punteros. Una base de datos en red consiste en un conjunto de registros conectados entre si mediante punteros. Los registros son en muchos aspectos parecidos a las entidades del modelo entidad-relación (E-R). Cada registro es un conjunto de campos (atributos), cada uno de los cuales sólo contiene un valor de datos. Los punteros son asociaciones entre exactamente dos registros. Por tanto, los punteros pueden considerarse una forma restringida (binaria) de relación en el sentido del modelo E-R. En cuanto a la dinamica, los modelos en red se carecterizan por ser navegacionales, es decir, la recuperacion y la actualizacion de la base de datos se lleva a cado registro a registor, y procedimentales, es decir, asumen el conocimiento de la estructura interna de la base de datos por parte del programador.
74. Como ejemplo, considérese una base de datos que represente una relación cliente-cuenta en un sistema bancario. Hay dos tipos de registros, cliente y cuenta. La base de datos de ejemplo de la Figura muestra que López tiene la cuenta C-102, González tiene las cuentas C-101 y C-201 y Abril tiene la cuenta C-305.
75. Los diagramas de estructura de datos son esquemas que representan el diseño de las bases de datos en red. Estos diagramas constan de dos componentes fundamentales: las cajas, que corresponden a tipos de registros, y las líneas, que corresponden a punteros. Los diagramas de estructuras de datos cumplen la misma finalidad que los diagramas E-R, es decir, especifican la estructura lógica global de la base de datos. Los diagramas E-R pueden transformarse en los diagramas de la estructura de datos correspondientes. DIAGRAMAS DE ESTRUCTURA DE DATOS
76. A modo de ejemplo, considérese el diagrama E-R de la Figura a, que consta de dos conjuntos de entidades, cliente y cuenta, relacionados mediante una relación binaria de varios a varios impositor, sin atributos descriptivos. El diagrama especifica que un cliente puede tener varias cuentas y que una cuenta puede pertenecer a varios clientes diferentes. El diagrama de la estructura de datos correspondiente se ilustra en la Figura b. El tipo de registro cliente corresponde al conjunto de entidades cliente. Incluye tres campos — nombre-cliente, calle-cliente y ciudad-cliente—, tal y como se ha definido anteriormente. De manera parecida, cuenta es el tipo de registro correspondiente al conjunto de entidades cuenta. Incluye los dos campos número-cuenta y saldo. Finalmente, la relación impositor ha sido sustituida por el puntero impositor. Si la relación impositor fuera de uno a varios de cliente a cuenta, el puntero impositor tendria una flecha que apuntaría al tipo de registro cliente. De manera parecida, si la relación impositor fuera de uno a uno, el puntero impositor tendría dos flechas, una que apuntaría al tipo de registro cuenta y otra que apuntaría al tipo de registro cliente.
77. Considérese el diagrama E-R siguiente de la Figura a, que consta de tres conjuntos de entidades — cuenta, cliente y sucursal— relacionadas mediante la relación general CCS sin atributos descriptivos. El diagrama específica que un cliente puede tener varias cuentas, cada una de ellas abierta en una sucursal bancaria específica, y que una cuenta puede pertenecer a varios clientes diferentes. Dado que los punteros pueden conectarse exactamente con dos tipos de registros diferentes, hay que conectar estos tres tipos de registros mediante un nuevo tipo de registro que se vincule directamente con cada uno de ellos. Para transformar el diagrama E-R de la Figura a en un diagrama la estructura de datos de red hay que crear un nuevo tipo de registro Renlace que pueda no tener ningún campo o tener un solo campo que contenga un identificador único. Este identificador lo proporciona el tema y no lo utiliza directamente el programa de aplicación. Este nuevo tipo de registro se denomina a veces tipo de registro ficticio (o enlace o conexión). También hay que crear tres punteros de varios a uno, ClienRenl, CuenRenl y SucRenl, tal y como se muestra en la Figura b. Si la relación CCS tuviera atributos descriptivos, se transformarían en campos del tipo de registro Renlace.
78.
79. La primera especificación de una norma para las bases de datos, denominada informe CODASYL DBTG 1971, la elaboró a finales de los años sesenta el grupo de trabajo sobre bases de datos (Database Task Group, DBTG). En el modelo DBTG sólo se pueden utilizar punteros de varios a uno. Los punteros de uno a uno se representan como punteros de varios a uno. No se permiten los punteros de varios a varios para simplificar la aplicación. Si la relación impositor es de varios a varios, el algoritmo de transformación debe refinarse de la manera siguiente. Considérese la relación mostrada en la Figura a. Para transformar la relación hay que crear un nuevo tipo de registro ficticio, Renlace, que puede no tener ningún campo o tener un solo campo que contenga un identificador único definido externamente, y dos punteros de varios a uno, ClienRenl y CuenRenl, tal y como se muestra en la Figura b. EL MODELO CODASYL DE DBTG
80. Dado que sólo se pueden utilizar punteros de varios a uno en el modelo DBTG, un diagrama de estructura de datos que consta de dos tipos de registro vinculados entre sí tiene la forma general de la Figura. Esta estructura se denomina conjunto DBTG en el modelo DBTG. El nombre del conjunto suele elegirse para que sea igual que el del puntero que conecta los dos tipos de registro. En cada uno de estos conjuntos DBTG, el tipo de registro A se denomi na propietario (o padre) del conjunto, y el tipo de registro B se denomina miembro (o hijo) del conjunto. Cada conjunto DBTG puede tener un número indefinido de apariciones del conjunto, es decir, casos reales de registros vinculados. Por ejemplo, en la Figura siguiente hay tres apariciones del conjunto correspondientes al conjunto DBTG de la Figura anterior.
81. Dado que no se permiten los punteros de varios a varios, cada aparición del conjunto tiene exactamente un propietario y cero o más registros miembros. Además, ningún registro miembro de un conjunto puede participar en más de una aparición del conjunto en ninguna ocasión. Los registros miembros, sin embargo, pueden participar simultáneamente en varias apariciones de conjuntos DBTG diferentes. El lenguaje de tratamiento de datos de la propuesta DBTG consta de órdenes que se incorporan en un lenguaje anfitrión. Las órdenes permiten a los programadores seleccionar registros de la base de datos de acuerdo con el valor de un campo especificado e iterar en los registros seleccionados mediante órdenes repetidas para obtener el registro siguiente. También se facilitan a los programadores órdenes para averiguar el propietario de un conjunto en el que tome parte un registro e iterar en los miembros de dicho conjunto. Y por supuesto que hay órdenes para actualizar la base de datos.
82. En el modelo DBTG los punteros se establecen añadiendo campos puntero a los registros que se asocian mediante ellos. Para mostrar la manera de hacerlo, supóngase que la relación impositor es de varios a uno de cuenta a cliente. Un registro cuenta sólo puede estar asociado con un registro cliente. Por tanto, para representar la relación impositor sólo hace falta un puntero en el registro cuenta. Sin embargo, los registros cliente pueden estar asociados con varios registros cliente. En vez de utilizar varios punteros en los registros cliente, se puede utilizar una estructura de anillo para representar todas las apariciones del conjunto DBTG impositor. En las estructuras de anillo, los registros de los tipos propietario y miembro de cada aparición del conjunto se organizan en listas circulares. Hay una lista circular por cada aparición del conjunto (es decir, por cada registro del tipo propietario). En la Figura 7.7 se muestra la estructura de anillo del ejemplo de la Figura 7.1. Examínese la aparición del conjunto DBTG que posee el registro «González». Hay dos registros de tipo miembro (cuenta). En vez de contener un puntero por cada registro miembro, el registro propietario (González) sólo contiene un puntero para el primer registro miembro (la cuenta C-101). Este registro miembro contiene un puntero al siguiente registro miembro (la cuenta C-201). Dado que el registro de la cuenta C-201 es el último registro miembro, contiene un puntero para el registro propietario. TÉCNICAS DE IMPLEMENTACIÓN
83. Establecer punteros de varios a varios utilizando punteros es significativamente más difícil. Por tanto, el modelo DBTG restringió los punteros a ser de varios a uno. La estrategia de implementación del modelo DBTG también proporcionó la base para el sistema de recuperación de datos DBTG.
84. Resulta evidente del estudio anterior que el modelo de red está estrechamente vinculado con su implementación. Como se vio anteriormente, los diseñadores de bases de datos tienen que crear tipos de registros artificiales incluso para establecer relaciones sencillas de varios a varios. A diferencia del modelo relacional, en el que las consultas pueden realizarse de una manera sencilla y declarativa, la realización de consultas resulta significativamente más complicada. Los programadores se ven obligados a pensar en términos de punteros y de la manera de atravesarlos para llegar a la información necesaria; el tratamiento de los datos en el modelo de red se denomina, por tanto, de navegación Así, el modelo de red aumenta de manera significativa el trabajo de los programadores, tanto para el diseño de las bases de datos como para el tratamiento de los datos, en comparación con el modelo relacional. Fue preferido al modelo relacional durante muchos años debido a que las primeras implementaciones del modelo relacional fueron muy poco eficientes. Hoy en día hay excelentes implementaciones del modelo relacional, por lo que el modelo de red ha perdido importancia.
85.
86.
87. Modelo jerárquico Un modelo de datos jerárquico es un modelo de datos en el cual los datos son organizados en una estructura parecida a un árbol. La estructura permite a la información que 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.
88. 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. Considere la estructura siguiente: En esta tabla, "el hijo" es el mismo tipo que "el padre". La jerarquía que declara EmpNo 10 es el jefe de 20, y30 y 40 cada informe a 20 es representado por la columna "Reporta". .
89.
90.
91. En este diagrama podemos observar que las flechas están apuntando de padres a hijos. Un padre (origen de una rama) puede tener una flecha apuntando a un hijo, pero un hijo siempre puede tener una flecha apuntando a su padre. El esquema de una base de datos se representa como una colección de diagramas de estructura de árbol. Para cada diagrama existe una única instancia de árbol de base de datos. La raíz de este árbol es un nodo ficticio. Los hijos de ese nodo son instancias de los registros de la base de datos. Cada una de las instancias que son hijos pueden tener a su vez, varias instancias de varios registros.
92.
93.
94.
95. Cuando la relación tiene atributos descriptivos, la transformación de un diagrama E-R a estructura de árbol se lleva a cabo cubriendo los siguientes pasos: Crear un nuevo tipo de registro. Crear los enlaces correspondientes. Consideremos que a la relación Alumno-Materia añadimos el atributo Cal a la relación que existe entre ambas, entonces nuestro modelo E-R resulta: Añadir el diagrama E-R
96.
97.
98.
99. Este modelo, bastante reciente, y propio de los modelos informáticos orientados a objetos, trata de almacenar en la base de datos los obj etos completos (estado y comportamiento). En bases de datos orientadas a objetos, los usuarios pueden definir operaciones sobre los datos como parte de la definición de la base de datos. Una operación (llamada función) se especifica en dos partes. La interfaz (o signatura) de una operación incluye el nombre de la operación y los tipos de datos de sus argumentos (o parámetros). La implementación (o método) de la operación se especifica separadamente y puede modificarse sin afectar la interfaz. Los programas de aplicación de los usuarios pueden operar sobre los datos invocando a dichas operaciones a través de sus nombres y argumentos, sea cual sea la forma en la que se han implementado. Esto podría denominarse independencia entre programas y operaciones. Modelo orientado a objetos
100. Un sistema es un conjunto de elementos que interactúan entre si, en un sistema orientado a objetos los elementos toman el nombre de objetos. Un sistema de información Orientado a Objetos no es Base de datos + programas, sino que es un conjunto de objetos colaborativos donde los objetos persistente son guardados en una Base de Datos. El propósito de los sistemas de bases de datos es la gestión de grandes cantidades de información. Las primeras bases de datos surgieron del desarrollo de los sistemas de gestión de archivos. Estos sistemas primero evolucionaron en bases de datos de red o en bases de datos jerárquicas y, más tarde, en bases de datos relacionales. Estructura de objetos El modelo orientado por objetos se basa en encapsular código y datos en una única unidad, llamada objeto. El interfaz entre un objeto y el resto del sistema se define mediante un conjunto de mensajes. Sistemas Orientados a Objetos
101.
102. Jerarquía de objetos o clases En una base de datos existen objetos que responden a los mismos mensajes, utilizan los mismos métodos y tienen variables del mismo nombre y tipo. Sería inútil definir cada uno de estos objetos por separado por lo tanto se agrupan los objetos similares para que formen una clase, a cada uno de estos objetos se le llama instancia de su clase. Todos los objetos de su clase comparten una definición común, aunque difieran en los valores asignados a las variables. Así que básicamente las bases de datos orientadas por objetos tienen la finalidad de agrupar aquellos elementos que sean semejantes en las entidades para formar un clase, dejando por separado aquellas que no lo son en otra clase.
103. Por ejemplo: Tomemos como referencia la entidad Alumno y la entidad Maestro. Donde los atributos considerados para cada uno son: Alumno : • Nombre • Dirección • Teléfono • Especialidad • Semestre • Grupo
104. Maestro : • Nombre • Dirección • Teléfono • Número económico • Plaza • RFC Los atributos de Nombre , Dirección y Teléfono se repiten en la entidad Alumno y Maestro , así que podemos agrupar estos elementos para formar la clase Persona, con dichos campos.
105. • Quedando por separado en Alumno : • Especialidad • Semestre • Grupo. • Y en Maestro : • Número Económico • Plaza • RFC.
106.
107. Interacción entre objetos. Los objetos se comunican entre si usando mensajes, la recepción de un mensaje provoca entonces que uno de los métodos de mi objeto sea ejecutado. Tipos de objetos Cuando clasificamos los objetos estamos generalizando las propiedades que puede tener el objeto, el tipo de objeto es un patrón para todos los objetos de este tipo y esto se denomina tipo de dato abstracto o más conocido como clase. Encapsulamiento Los datos y los métodos para manipular los datos son una sola unidad y están encapsulados en este objeto, los datos que son parte del objeto pueden ser manipulados únicamente por la invocación de los métodos publicados en la interfase del objeto. Entonces los datos – atributos son descritos junto con la rutina (método) que permite manipularlos.
108. Ocultamiento de la Información. Los detalles de la implementación de los métodos son ocultados para los clientes. Herencia. Un tipo de objeto puede tener subtipos los cuales son clases especializadas que heredan los atributos y métodos de la clase general. Se pueden crear muchas agrupaciones (clases) para simplificar un modelo así que una jerarquía (en forma gráfica) puede quedar muy extensa, en estos casos tenemos que tener bien delimitados los elementos que intervienen en una clase y aquellos objetos que las heredan. Polimorfismo. Una subclase tiene la posibilidad de sobrescribir los métodos heredados, con esto pueden existir dos clases que a pesar de poseer los mismos atributos e interfaces son diferentes.
109. Los lenguajes de programación orientados por objetos requieren que toda la interacción con objetos se realiza mediante el envío de mensajes. Consideremos el ejemplo de alumno-cursa-materia deseamos realizar la consulta de los alumnos que cursan la materia de Base de Datos 1, para realizar esta consulta se tendría que enviar un mensaje a cada instancia alumno. En sí la estructuración de modelos orientados por objetos simplifica una estructura evitando elementos o variables repetidas en diversas entidades, sin embargo el precio de esto es dedicarle un minucioso cuidado a las relaciones entre las clases cuando un modelo es complejo, la dificultad del manejo de objetos radica en la complejidad de las modificaciones y eliminaciones de clases, ya que de tener variables que heredan otros objetos se tiene que realizar una reestructuración que involucra una serie de pasos complejos. Consultas orientadas por objetos