UNIDAD 1: CONCEPTOS Y DISEÑO DE BASE DE

DATOS

SESIÓN 3: MODELOS DE DATOS.

1. Modelado de datos.
2. La importancia de los modelos de
datos.
3. Elementos básicos de un modelo de
datos. CONTENIDOS
4. Reglas denegocio.
5. La evolución de los modelos de datos.
6. Grados de abstracción de datos

PRODUCTO DE LA Informe diferenciando requerimientos de

SESIÒN reglas del negocio
Motivación
Saberes previos

Tomado de: Coronel, Morris y Rob, BASESDEDATOS,Novena Edición

Conflicto cognitivo

Responder:
¿Cuál es la diferencia entre el diseño
conceptual, lógico y físico?
 Conflicto cognitivo

Diseño Conceptual Diseño Lógico

Este diseño es independiente del modelo Partiendo del diseño conceptual
de DDBB usado, del ordenador, del obtenido en la fase anterior, llegamos a
sistema gestor de bases de datos, etc… un diseño lógico. Transformamos las
Simplemente se estudia el problema y se entidades y relaciones obtenidas del
seleccionan los elementos del mundo modelo anterior en tablas. Para ello
real que vamos a modelar. Este diseño es usamos la normalización.
al que corresponde el diagrama E/R
Conflicto cognitivo

Diseño Físico

Este diseño si depende del ordenador, del

sistema gestor de DDBB, etc… En este caso,
empleando el gestor de la DDBB, se
implementan las tablas de las DDBB con sus
características, organización y estructuras de
almacenamiento interno.
 LOGRO DE LA
SESIÓN

Al término de la sesión, el estudiante elabora la primera versión

del modelo general de una Base de Datos, tomando como
referencia un caso de estudio y siguiendo de manera ordenada y
completa los pasos indicados en los instructivos de los formatos
de entregables presentados en clase.
Construcción de conocimiento

MODELADO DE DATOS Y MODELOS DE DATOS

• “El diseño de bases de datos se concentra en la forma

en que la estructura de bases de datos se usará para
guardar y administrar datos del usuario final” (Coronel,
Morris y Rob, “Bases de Datos” – 9na. Edición)
• El modelado de datos abarca la obtención y el análisis
de los requerimientos del negocio para generar un
modelo que represente dichos requerimientos.
 Construcción de conocimiento

¿QUÉ ES UN REQUERIMIENTO?

• Un requerimiento es algo que el producto debe hacer o

una característica que debe tener.
• Un requisito existe por el tipo de demanda que tiene el
producto o porque el cliente quiere que el requisito sea
parte del producto entregado.
• La tarea de todo analista de requisitos es hablar con la
gente, entenderla, escuchar lo que dicen y también lo
que no dicen, para entender lo que necesitan
Construcción de conocimiento

TIPOS DE REQUERIMIENTOS
Construcción de conocimiento

EL MODELO CONCEPTUAL DE DATOS

• El Modelo Conceptual de Datos es una imagen mental

de un objeto físico que nos puede resultar familiar y no
necesariamente hace referencia a una base de datos.
• En un nivel muy alto, el modelo conceptual describe los
objetos para los cuales una organización desea
recolectar datos y las relaciones que existen entre estos
objetos.
• El objetivo principal de un diseño conceptual de base de
datos es construir un modelo conceptual de datos.
EL MODELO CONCEPTUAL DE DATOS

-- - ---
--
Construcción de conocimiento

ELEMENTOS BÁSICOS DE UN MODELO DE DATOS

• Los modelos conceptuales tienen tres elementos básicos:

• Tipo de entidad: Es una colección de cosas de interés tales
como personas, lugares o eventos. Se representan por un
rectángulo.
• Atributo: Es una propiedad de un tipo de entidad o relación.
Cada atributo tiene un tipo de dato que define el tipo de valores
y operaciones permitidas sobre dicho atributo.
• Relación: Es una asociación nombrada entre los tipos de
entidades. Una relación representa una asociación en dos
sentidos (o bidireccional) entre entidades. La mayoría de las
relaciones involucran dos distintos tipos de entidad.
Construcción de conocimiento

CARDINALIDAD DE LAS RELACIONES

• Las cardinalidades restringen el número de objetos (o entidades)

que participan en una relación. En un ERD el número mínimo y
máximo de cardinalidades se especifican para las dos direcciones
de la relación.
• Las cardinalidades se representan a través de la notación
denominada pata de cuervo (crow’s foot), la misma que usa tres
símbolos:
• O  Cardinalidad cero (ninguna entidad relacionada)
• |  Cardinalidad uno (una entidad relacionada)
•  Cardinalidad muchos (muchas entidades relacionadas)
Construcción de conocimiento

CARDINALIDAD DE LAS RELACIONES

Clasificación de las Cardinalidades

Clasificación Restricción de las cardinalidades
Obligatoria Cardinalidad mínima >= 1
Opcional Cardinalidad mínima = 0
Funcional o de valor único Cardinalidad máxima = 1
1 – M (uno a muchos) Cardinalidad máxima = 1 en una
dirección y cardinalidad máxima > 1 en la
otra dirección
M – N (muchos a muchos) Cardinalidad máxima > 1 en ambas
direcciones
1 – 1 (uno a uno) Cardinalidad máxima = 1 en ambas
direcciones
 REGLAS DE NEGOCIOS

• Es una descripción breve, precisa y no ambigua de una política, procedimiento

o principio dentro de una organización específica (Coronel, Morris y Rob,
“Bases de Datos” – 9na. Edición).
• Las reglas de negocio, correctamente escritas, se usan para definir entidades,
atributos, relaciones y restricciones. Ejemplos:
o Un cliente puede generar muchas facturas.
o Una sesión de capacitación no puede ser programada para menos de 10
o para más de 30 empleados.
• Las principales fuentes de reglas de negocios son los gerentes de compañías,
directores de políticas, gerentes de departamento y documentación escrita de
la institución tales como procedimientos, normas, manuales de operaciones,
etc. (Coronel, Morris y Rob, “Bases de Datos” – 9na. Edición).
• Por regla general, un sustantivo en una regla de negocios se convertirá en una
entidad dentro del modelo y un verbo que asocie sustantivos los convertirá en
una relación entre entidades.
 LA EVOLUCIÓN DE LOS MODELOS DE DATOS

ERA GENERACION ORIENTACION PRINCIPALES

CARACTERISTICAS
1,960’s Primera Generación Archivo Estructuras de archivo
e interfaces de
programa propietarios
1,970’s Segunda Generación Navegación en redes Redes y jerarquías de
registros relacionados.
Interfaces de programación
estándar
1,980’s Tercera Generación Relacional Lenguajes no
procedurales, optimización,
procesamiento
transaccional
1,990’s Cuarta Generación Objeto Multimedia,
procesamiento distribuido,
procesamiento de
datawarehouse, habilitación
para XML.
2,000’s Quinta Generación DBMS híbrido en XML Soporte a datos
no estructurados
 LA EVOLUCIÓN DE LOS MODELOS DE DATOS

• La primera generación
soportaba búsquedas
secuenciales y aleatorias, pero
el usuario necesitaba escribir
un programa de computadora
para obtener el acceso.
• Como los sistemas de primera
generación no ofrecían
suficiente soporte para
relacionar datos, usualmente
eran vistos como sistemas de
procesamiento de archivos en
vez de DBMS.
 LA EVOLUCIÓN DE LOS MODELOS DE DATOS

• Los productos de la segunda

generación fueron los primeros
DBMS reales, ya que podían
administrar muchas entidades y
relaciones. Sin embargo, para
obtener el acceso a los datos
todavía se tenía que escribir un
programa.
• Los sistemas de segunda
generación son conocidos como “
navegacionales”, ya que el
programador tenía que escribir
código para navegar entre una red
de registros ligados.

18
 LA EVOLUCIÓN DE LOS MODELOS DE DATOS

• A los sistemas de tercera

generación se les conoce como
DBMS relacionales, porque se
basan en relaciones matemáticas
y operadores asociados.
• El desarrollo más importante de
esta generación provino de los
lenguajes no procedurales para el
acceso a Bases de Datos.

19
 LA EVOLUCIÓN DE LOS MODELOS DE DATOS
• Los DBMS de cuarta generación
han extendido las fronteras de la
tecnología de BD hacia otros datos
no convencionales (como por
ejemplo imágenes, videos, mapas,
sonidos, animaciones, etc.),
internet y el procesamiento de los
data warehouse.
• Debido a que estos sistemas
consideran cada tipo de dato como
un objeto a administrar, a los
sistemas de cuarta generación
algunas veces se les llama
“orientados a objetos” o “
relacionados con objetos”.
 LA EVOLUCIÓN DE LOS MODELOS DE DATOS

• Los DBMS de quinta generación

conservan las ventajas del modelo
relacional y ofrecen soporte para la
programación orientada a objetos.
• Asimismo, los servicios de BD en la
nube tales como Microsoft Data
Services son característicos de esta
generación. Estos servicios
permiten que las empresas de
cualquier tamaño sean capaces de
guardar sus datos en BD
relacionales sin incurrir en altos
costos de hardware.
 GRADOS DE ABSTRACCIÓN DE DATOS
• Vienen a ser los niveles a través de los cuales es posible modelar
una base de datos, dependiendo del detalle o profundidad del
modelo y de la vista o enfoque hacia el cual está orientado el
modelo en construcción.
• Se conoce también como arquitectura ANSI / SPARC, según el
comité que la propuso (mediados de los 70’s).
• Sirve para compartimentalizar las descripciones de la base de
datos.
• Su objetivo es separar las aplicaciones de usuarios de las bases de
datos físicas (independencia de los datos). Posee tres niveles:
• Nivel Externo.
• Nivel Conceptual.
• Nivel Interno
MODELADO DE DATOS Y MODELOS DE DATOS
 CONCLUSIONES

Los usuarios no tienen porque conocer como están

organizados y almacenados los datos.

Por este motivo una base de datos debe presentar los

datos de forma que el usuario pueda interpretarlos y
modificarlos.