CASO ACTIVIDAD 2.

DIFERENCIAR LOS MODELOS DE DATOS VIGENTES Y SUS BASES CONCEPTUALES

TENIENDO EN CUENTA SUS DIFERENTES APLICACIONES

ANDERSON RAFAEL VALDEZ RAMÍREZ

APRENDIZ

MILTON MANUEL ORTIZ LOPEZ

INSTRUCTOR

ACTIVIDAD SEMANA 2 EVIDENCIA 2

BASE DE DATOS GENERALIDADES Y SISTEMAS DE GESTIÓN

AGOSTO 2020
Modelo relacional realizado en el motor de Base de Datos Microsoft Access 2016
REGISTRO DE DATOS EN LA BASE DE DATOS COLEGIO SAN JORGE
 SOLUCIÓN PREGUNTAS GUÍA DE APRENDIZAJE 2
1. Diseño conceptual de bases de datos. Modelo Entidad-Relación (E-R).

DISEÑO CONCEPTUAL DE BASES DE DATOS. MODELO ENTIDAD – RELACIÓN.

Introducción
Metodología de diseño de bases de datos
Modelos de datos
El modelo entidad – relación
Metodología de diseño conceptual
 Introducción

¿Principal causa de fracaso en el diseño de sistemas de información? La poca confianza en las metodologías
de diseño de bases de datos.

Consecuencias:

 Se subestiman el tiempo o los recursos necesarios.

 Las bases de datos son inadecuadas o ineficientes.
 La documentación es limitada.
 El mantenimiento es difícil.
Metodología de diseño de base de datos
Especificación de Requisitos

Diseño Conceptual

Esquema Conceptual

Diseño Lógico Normalización

Esquema lógico

Diseño Físico

Esquema Físico
Esquema conceptual Descripción de alto nivel del contenido de
información de la base de datos, independiente del
SGBD que se vaya a utilizar.
Modelo conceptual Lenguaje que se utiliza para describir esquemas
conceptuales.

Propósito Obtener un esquema completo que lo exprese todo.

Esquema lógico Descripción de la estructura de la base de datos según

el modelo del SGBD que se vaya a utilizar.

Modelo lógico Lenguaje que se utiliza para describir esquemas

lógicos; hay varios modelos lógicos: de red, relacional,
orientado a objetos, ...
Propósito Obtener una representación que use de la manera más
eficiente los recursos disponibles en el modelo lógico
para estructurar datos y modelar restricciones.

El diseño lógico depende del modelo de BD que soporta el SGBD.

Esquema físico Descripción de la implantación de una BD en la
memoria secundaria: estructuras de almacena-
miento y métodos usados para tener un acceso
efectivo a los datos. El diseño físico se adapta
al SGBD específico que se va a utilizar.

Se expresa haciendo uso del lenguaje de definición de datos del SGBD.

Por ejemplo, en SQL las sentencias que se utilizan son las siguientes:

CREAT DATABASE
E
CREAT TABLE CREATE SCHEMA
E
CREAT VIEW CREATE SNAPSH
E OT
CREAT INDEX CREATE CLUSTER
E
 Tipo de SGBD SGBD Específico

Diseño Conceptual NO NO

Diseño Lógico SI NO

Diseño Físico SI SI

Modelos de datos

Esquema: Descripción de la estructura de los datos de interés.

Un esquema conceptual se representa mediante un modelo conceptual de datos.

Cualidades que debe poseer un modelo conceptual:

 Expresividad.
 Simplicidad.
 Minimalidad.
 Formalidad.

Además, hay que añadir aserciones que complementen el esquema.

 El modelo entidad – relación

Es el modelo conceptual más utilizado para el diseño conceptual de bases de datos. Fue
introducido por Peter Chen en 1976.
Entidad

 Tipo de objeto sobre el que se recoge información: cosa, persona, concepto

abstracto o suceso (coches, casas, empleados, clientes, empresas, oficios, diseños
 de productos, conciertos, excursiones, etc.).

 Las entidades 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.

Relación (interrelación)

 Correspondencia o asociación entre dos o más entidades.

 Las relaciones se representan gráficamente mediante rombos y su nombre aparece en el interior.
 La cardinalidad con la que una entidad participa en una relación especifica el número mínimo y el número máximo
 de correspondencias en las que puede tomar parte cada ocurrencia de dicha entidad.

Atributo
 Característica de interés sobre una entidad o sobre una relación.
 La cardinalidad de un atributo indica el número mínimo y el número máximo de valores que puede tomar para cada
ocurrencia de la entidad o relación a la que pertenece. El valor por omisión es (1,1).
Jerarquía de generalización
 La entidad E es una generalización de las entidades E1, E2, ... En, si las ocurrencias de éstas son también
ocurrencias de E. Todas las propiedades de la entidad genérica son heredadas por las subentidades.
 Cada jerarquía es total o parcial, y exclusiva o superpuesta.
 Un subconjunto es un caso particular de generalización con una sola entidad como subentidad. Un subconjunto
siempre es una jerarquía parcial y exclusiva.
Atributo compuesto
 Grupo de atributos que tienen afinidad en cuanto a su significado o en cuanto a su uso.
 Un atributo compuesto se representa gráficamente mediante un óvalo.
Identificador
 Un identificador de una entidad es un atributo o conjunto de atributos que determina de modo único cada
ocurrencia de esa entidad. Todo identificador debe cumplir

1) no pueden existir dos ocurrencias de la entidad con el mismo valor del identificador,
2) si se omite cualquier atributo del identificador, la condición (1) deja de cumplirse.

 Toda entidad tiene al menos un identificador y puede tener varios identificadores alternativos.

Metodología de diseño conceptual

 Para cada área funcional de la empresa se construye un esquema conceptual local siguiendo estos pasos:

1) Identificar las entidades.

2) Identificar las relaciones.
 3) Identificar los atributos y asociarlos a entidades y relaciones.
4) Determinar los dominios de los atributos.
5) Determinar los identificadores.
6) Determinar las jerarquías de generalización (si las hay).
7) Dibujar el diagrama entidad – relación.
8) Revisar el esquema conceptual local con el usuario.

Ejemplo
¿Qué es una base de datos relacional?
Una base de datos relacional es un tipo de base de datos que almacena y proporciona acceso a puntos de datos
relacionados entre sí. Las bases de datos relacionales se basan en el modelo relacional, una forma intuitiva y directa de
representar datos en tablas. En una base de datos relacional, cada fila de la tabla es un registro con un ID único llamado
clave. Las columnas de la tabla contienen atributos de los datos, y cada registro generalmente tiene un valor para cada
atributo, lo que facilita el establecimiento de las relaciones entre los puntos de datos.

Un ejemplo de base de datos relacional

A continuación se muestra un ejemplo simple de dos tablas que una pequeña empresa podría utilizar para procesar
pedidos de sus productos. La primera tabla es una tabla de información del cliente, por lo que cada registro incluye el
nombre, dirección, información de envío y facturación, número de teléfono y otra información de contacto de un cliente.
Cada bit de información (cada atributo) está en su propia columna, y la base de datos asigna un ID único (una clave) a
cada fila. En la segunda tabla, una tabla del pedido del cliente, cada registro incluye el ID del cliente que realizó el pedido,
el producto solicitado, la cantidad, el tamaño y el color seleccionados, etcétera, pero no el nombre o la información de
contacto del cliente.

Estas dos tablas tienen solo una cosa en común: la columna de ID (la clave). Gracias esa columna en común, la base de
datos relacional puede crear una relación entre las dos tablas. Entonces, cuando la aplicación de procesamiento de
pedidos de la empresa envía un pedido a la base de datos, la base de datos puede ir a la tabla de pedidos del cliente,
obtener la información correcta sobre el pedido del producto y usar el ID del cliente de esa tabla para buscar la
información de facturación y envío del cliente en la tabla de información del cliente. Entonces, el almacén puede extraer el
producto correcto, el cliente puede recibir la entrega del pedido a tiempo y la empresa puede recibir el pago.

¿Cómo se estructuran las bases de datos relacionales?

El modelo relacional significa que las estructuras lógicas de datos—las tablas de datos, vistas e índices—están
separadas de las estructuras físicas de almacenamiento. Esta separación significa que los administradores de bases de
datos pueden administrar el almacenamiento físico de datos sin afectar el acceso a esos datos como una estructura
lógica. Por ejemplo, cambiar el nombre de un archivo de base de datos no cambia el nombre de las tablas almacenadas
en él.

La distinción entre lógica y física también se aplica a las operaciones de la base de datos, que son acciones claramente
definidas que permiten a las aplicaciones manipular los datos y las estructuras de la base de datos. Las operaciones
lógicas permiten que una aplicación especifique el contenido que necesita, mientras que las operaciones físicas
determinan cómo se debe acceder a esos datos y luego realizan la tarea.

Para garantizar que los datos sean siempre precisos y accesibles, las bases de datos relacionales siguen ciertas reglas
de integridad. Por ejemplo, una regla de integridad puede especificar que no se permitan filas duplicadas en una tabla,
para eliminar la posibilidad de que ingrese información errónea en la base de datos.

El modelo relacional
En los primeros años de las bases de datos, cada aplicación almacenaba datos en su propia estructura única. Cuando los
desarrolladores querían crear aplicaciones para usar esos datos, tenían que saber mucho sobre la estructura de datos
particular para encontrar los datos que necesitaban. Estas estructuras de datos eran ineficientes, difíciles de mantener y
difíciles de optimizar para ofrecer un buen rendimiento de la aplicación. El modelo de base de datos relacional se diseñó
para resolver el problema de varias estructuras de datos arbitrarias.

El modelo relacional proporcionó una forma estándar de representar y consultar datos que cualquier aplicación podría
utilizar. Desde el principio, los desarrolladores reconocieron que la principal fortaleza del modelo de base de datos
relacional estaba en el uso de tablas, que eran una forma intuitiva, eficiente y flexible de almacenar y acceder a
información estructurada.
Con el tiempo, cuando los desarrolladores comenzaron a utilizar el lenguaje de consulta estructurado (SQL) para escribir
y consultar datos en una base de datos, surgió otra fortaleza del modelo relacional. Durante muchos años, se utilizó
ampliamente el SQL como lenguaje para consultas de bases de datos. El SQL, que se basa en el álgebra relacional,
proporciona un lenguaje matemático internamente consistente que facilita la mejora del rendimiento de todas las
consultas de la base de datos. En comparación, otros enfoques deben definir consultas individuales.

Beneficios de las bases de datos relacionales

Las organizaciones de todo tipo y tamaño utilizan el modelo relacional simple pero poderoso para una amplia variedad de
necesidades de información. Las bases de datos relacionales se utilizan para hacer seguimiento de los inventarios,
procesar transacciones de comercio electrónico, administrar grandes cantidades de información de clientes de misión
crítica y mucho más. Se puede considerar una base de datos relacional para cualquier necesidad de información en la
que los puntos de datos se relacionen entre sí y se deban administrar de una manera segura, consistente y basada en
reglas.

Las bases de datos relacionales existen desde la década de 1970. Actualmente, las ventajas del modelo relacional
continúan convirtiéndolo en el modelo más aceptado para bases de datos.

Consistencia de los datos

El modelo relacional es el mejor para mantener la consistencia de los datos en todas las aplicaciones y copias de la base
de datos (denominadas instancias). Por ejemplo, cuando un cliente deposita dinero en un cajero automático y, luego, mira
el saldo de la cuenta en un teléfono móvil, el cliente espera ver que ese depósito se refleje inmediatamente en un saldo
de cuenta actualizado. Las bases de datos relacionales se destacan en este tipo de consistencia de datos, lo que
garantiza que múltiples instancias de una base de datos tengan los mismos datos todo el tiempo.
Es difícil para otros tipos de bases de datos mantener este nivel de coherencia oportuna con grandes cantidades de
datos. Algunas bases de datos recientes, como NoSQL, solo pueden proveer “consistencia eventual.” Bajo este principio,
cuando la base de datos se escala o cuando varios usuarios acceden a los mismos datos al mismo tiempo, los datos
necesitan algo de tiempo para “ponerse al día.” La consistencia eventual es aceptable para algunos usos, como para
mantener listados en un catálogo de productos, pero para operaciones comerciales críticas como transacciones de un
carrito de compras, la base de datos relacional sigue siendo el estándar de oro.

Compromiso y atomicidad
Las bases de datos relacionales manejan las reglas y políticas comerciales en un nivel muy detallado, con políticas
estrictas sobre el compromiso (es decir, hacer un cambio permanente en la base de datos). Por ejemplo, considere una
base de datos de inventario que hace seguimiento de tres partes que siempre se usan juntas. Cuando se extrae una
parte del inventario, las otras dos también se deben extraer. Si una de las tres partes no está disponible, ninguna de las
partes debe quitarse—las tres partes deben estar disponibles antes de que la base de datos se comprometa. Una base
de datos relacional no se comprometerá por una parte hasta que sepa que puede comprometerse por las tres. Esta
capacidad de compromiso multifacética se llama atomicidad. La atomicidad es la clave para mantener la precisión de los
datos en la base de datos y garantizar que cumpla con las reglas, regulaciones y políticas de la empresa.

ACID y bases de datos relacionales

Las transacciones de bases de datos relacionales se definen mediante cuatro propiedades cruciales: Atomicidad,
consistencia, aislamiento y durabilidad—a los que se refiere típicamente como ACID.

La atomicidad define todos los elementos que conforman una transacción completa en la base de datos.
La consistencia define las reglas para mantener los puntos de datos en un estado correcto después de una transacción.
El aislamiento mantiene el efecto de una transacción invisible para otros hasta que se comprometa, para evitar
confusiones.
La durabilidad garantiza que los cambios en los datos se vuelvan permanentes una vez que se confirma la transacción.
Procedimientos almacenados y bases de datos relacionales
El acceso a los datos implica muchas acciones repetitivas. Por ejemplo, una consulta simple para obtener información de
una tabla de datos puede necesitar repetirse cientos o miles de veces para producir el resultado deseado. Estas
funciones de acceso a los datos requieren algún tipo de código para acceder a la base de datos. Los desarrolladores de
aplicaciones no desean escribir un código nuevo para estas funciones en cada aplicación nueva. Afortunadamente, las
bases de datos relacionales permiten procedimientos almacenados, que son bloques de código a los que se puede
acceder con una simple llamada de aplicación. Por ejemplo, un solo procedimiento almacenado puede proporcionar un
etiquetado de registro consistente para usuarios de varias aplicaciones. Los procedimientos almacenados también
pueden ayudar a los desarrolladores a garantizar que ciertas funciones de datos en la aplicación se implementen de una
manera específica.

Bloqueo de bases de datos y concurrencia

Pueden surgir conflictos en una base de datos cuando varios usuarios o aplicaciones intentan cambiar los mismos datos
al mismo tiempo. Las técnicas de bloqueo y concurrencia reducen la posibilidad de conflictos mientras mantienen la
integridad de los datos.

El bloqueo evita que otros usuarios y aplicaciones accedan a los datos mientras se actualizan. En algunas bases de
datos, el bloqueo se aplica a toda la tabla, lo que crea un impacto negativo en el rendimiento de la aplicación. Otras
bases de datos, como las bases de datos relacionales de Oracle, aplican bloqueos a nivel de registro, lo que deja
disponibles los otros registros dentro de la tabla, lo que ayuda a garantizar un mejor rendimiento de la aplicación.
La concurrencia gestiona la actividad cuando varios usuarios o aplicaciones realizan consultas al mismo tiempo en la
misma base de datos. Esta capacidad proporciona el acceso correcto a los usuarios y las aplicaciones de acuerdo con las
políticas definidas para el control de datos.

¿Qué buscar a la hora de seleccionar una base de datos relacional?

El software que se utiliza para almacenar, administrar, consultar y recuperar datos almacenados en una base de datos
relacional se denomina sistema de gestión de bases de datos relacionales (RDBMS). El RDBMS proporciona una interfaz
entre usuarios y aplicaciones y la base de datos, así como funciones administrativas para administrar el almacenamiento,
el acceso y el rendimiento de los datos.

Varios factores pueden guiar su decisión al momento de elegir entre tipos de bases de datos y productos de bases de
datos relacionales. El RDBMS que elija dependerá de las necesidades de su negocio. Hágase las siguientes preguntas:

¿Cuáles son nuestros requisitos de precisión de datos? ¿El almacenamiento de datos y la precisión dependerán de la
lógica empresarial? ¿Nuestros datos tienen requisitos estrictos de precisión (por ejemplo, datos financieros e informes
gubernamentales)?
¿Necesitamos escalabilidad? ¿Cuál es la escala de los datos a administrar y cuál es su crecimiento previsto? ¿Será
necesario que el modelo de base de datos admita copias de base de datos duplicadas (como instancias separadas) para
la escalabilidad? Si es así, ¿puede mantener la consistencia de los datos en esas instancias?
¿Qué tan importante es la concurrencia? ¿Varios usuarios y aplicaciones necesitarán un acceso simultáneo a los datos?
¿El software de la base de datos admite concurrencia mientras protege los datos?
¿Cuáles son nuestras necesidades de rendimiento y confiabilidad? ¿Necesitamos un producto de alto rendimiento y alta
confiabilidad? ¿Cuáles son los requisitos para el rendimiento de la consulta-respuesta? ¿Cuáles son los compromisos de
los proveedores para los acuerdos de nivel de servicio (SLA) o tiempo de inactividad no planificado?
4. Introducción
Llama la atención el desarrollo sobresaliente de cualquier conjunto de datos organizados para su almacenamiento en la
memoria de un ordenador o computadora en nuestros días, y logre un diseño para facilitar su mantenimiento y acceso de
una forma estándar.

En este trabajo se presentan los sistemas de bases de datos, haciendo antes un repaso por su historia, su definición, sus
papeles en el entorno, sus funciones sus ventajas e inconvenientes, sus lenguajes, sus modelos, la clasificación de los
sistemas de gestión de base de datos(o Clasificación de modelos) y observando los software existentes en el mercado,
su modelo correspondiente y un cuadro comparativo de tres software de modelo relacional.

Hay dos buenas razones para la siguiente investigación. En primer lugar, el conocer los acontecimientos que dieron lugar
al sistema gestor de base de datos nos proporciona cobertura detallada y comprensiva de su origen. En segundo lugar, si
en algún momento fuera necesario convertir un sistema de gestión de base de datos, alcanzar cómo trabaja este sistema
puede ser una ayuda esencial en el ámbito de los negocios, diseño e implementación de estrategias para la relación
cliente/servidor.

Historia
RELATO

Susan Broadbent, CEO, y Sanford Mallon, CIO (director de sistemas de información), de la compañía International
Product Dstribution, discuten animadamente sobre la tecnología de los sistemas. Susan, viendo la oportunidad de hacer
una broma, le provoco: "¿Sandy, quieres que pasemos a un sistema de base datos cliente/servidor?" "¿Es esta una mas
de tus ideas atolondradas?" Sanford le respondió:" ¿Atolondrada? ¿Alguna vez he hecho yo una propuesta que no
hubiera sido concebida con brillantez y ejecutada con absoluta precisión?"
"Bien, veamos. Cuando tú llegaste aquí, nos llevamos de nuestro sistema manual a un sistema orientado a archivos.
Luego vino el sistema de base de datos en red, y después las relacionales. Ahora quieres ir hacia una plataforma
cliente/servidor. Si estos esquemas fueron concebidos brillantemente, ¿Por qué hay que cambiarlos al cabo de pocos
años?"

Sanford se rio. La sonrisa de Susan le decía que ella era consciente de las razones de cada cambio y de los beneficios
significativos cosechados por la compañía en cada ocasión. Él contesto:"Ha sido un largo camino mantenerse avanzada
a la par que la tecnología, ¿cierto o falso?"

"Si. Pero tú has sido excepcional al permanecer al tanto de los desarrollos y movernos hacia ellos cuando mas
contribuirían a nuestro negocio. Y pensar que todo empezó de un modo tan simple…"

Concepto y origen de las BD y de los SGBD

Las aplicaciones informáticas de los años sesenta acostumbraban a darse totalmente por lotes (batch) y estaban
pensadas para una tarea muy específica relacionada con muy pocas entidades tipo. Cada aplicación (una o varias
cadenas de programas) utilizaba ficheros de movimientos para actualizar (creando una copia nueva) y/o para consultar
uno o dos ficheros maestros o, excepcionalmente, más de dos.

Cada programa trataba como máximo un fichero maestro, que solía estar sobre cinta magnética y, en consecuencia, se
trabajaba con acceso secuencial. Cada vez que se le quería añadir una aplicación que requería el uso de algunos de los
datos que ya existían y de otros nuevos, se diseñaba un fichero nuevo con todos los datos necesarios (algo que
provocaba redundancia) para evitar que los programas tuviesen que leer muchos ficheros.
A medida que se fueron introduciendo las líneas de comunicación, los terminales y los discos, se fueron escribiendo
programas que permitían a varios usuarios consultar los mismos ficheros on-line y de forma simultánea. Más adelante fue
surgiendo la necesidad de hacer las actualizaciones también on-line.

A medida que se integraban las aplicaciones, se tuvieron que interrelacionar sus ficheros y fue necesario eliminar la
redundancia. El nuevo conjunto de ficheros se debía diseñar de modo que estuviesen interrelacionados; al mismo tiempo,
las informaciones redundantes (como por ejemplo, el nombre y la dirección de los clientes o el nombre y el precio de los
productos), que figuraban en los ficheros de más de una de las aplicaciones, debían estar ahora en un solo lugar. El
acceso on-line y la utilización eficiente de las interrelaciones exigían estructuras físicas que diesen un acceso rápido,
como por ejemplo los índices, las multilistas, etc.

Estos conjuntos de ficheros interrelacionados, con estructuras complejas y compartidos por varios procesos de forma
simultánea (unos on-line y otros por lotes), recibieron al principio el nombre de Data Banks, y después, a inicios de los
años setenta, el de Data Bases. Aquí los denominamos bases de datos (BD). El software de gestión de ficheros era
demasiado elemental para dar satisfacción a todas estas necesidades. Por ejemplo, el tratamiento de las interrelaciones
no estaba previsto, no era posible que varios usuarios actualizaran datos simultáneamente, etc.