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

Esquema Conceptual

Normalización

Esquema lógico

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:

CREATE DATABASE
CREATE TABLE CREATE SCHEMA
CREATE VIEW CREATE SNAPSHOT
CREATE INDEX CREATE CLUSTER

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.