Академический Документы
Профессиональный Документы
Культура Документы
datos
RECOPILACIÓN: DR. A.D. Y DR.B.M. MIGUEL ANGEL MUÑOZ
ALVARADO
Modelo Entidad Relación
En el diseño de bases de datos se distinguen principalmente dos fases de diseño:
◦ La fase de modelado conceptual, que es la descripción del mundo real (una organización) de acuerdo
con un modelo altamente semántico e independiente del SGBD en el que posteriormente se vaya hacer
la implementación de la base de datos.
◦ La fase de diseño lógico, en la cual se ha de obtener un esquema que responda a la estructura lógica
especifica del SGBD que se vaya utilizar en cada caso, por lo que dicho esquema está sometido a las
restricciones que imponga el modelo del SGBD en concreto.
Modelo Entidad Relación
El Modelo de Entidad Relación es un modelo de datos basado en una percepción del mundo
real que consiste en un conjunto de objetos básicos llamados entidades y relaciones entre estos
objetos, implementándose en forma gráfica a través del Diagrama Entidad Relación.
Elementos esenciales:
Entidad: Clase de objetos relevantes y distinguibles del mundo, que son los sujetos de interés
para una organización. Ej: Cliente, Empleado, Pedido, Sucursal, Factura, etc.
Relación: Conexión, asociación entre dos entidades (relación binaria)
Atributo: Propiedad esencial o característica interesante (para la organización) de una entidad
Modelo Entidad Relación
En el proceso de diseño se recolecta la cantidad máxima de información para llevar acabo el
diseño conceptual, lógico y físico de la base de datos.
Los diseñadores entrevistan a los futuros usuarios de la base de datos para documentar sus
necesidades de información. En paralelo, conviene definir los requerimientos funcionales que
consisten en operaciones (transacciones) que se aplicarán a la base de datos, e incluyen la
obtención de datos y la actualización.
Modelo Entidad Relación
Etapas a
considerar
Recolección y análisis de requerimientos
de datos.
Analizar un problema del mundo real
Proceso durante el cual los diseñadores entrevistan a los futuros usuarios de la base de datos
para entender y documentar sus requerimientos de información.
Primeramente debe mantenerse el funcionamiento del flujo de información.
Con esto tratar de determinar la idea del proyecto.
Cuando queremos crear una base de datos debemos saber, ¿Para que se está creando la base de
datos?.
NOTA: El resultado de este paso será un conjunto de requerimientos del usuario redactado en
forma explícita
Requerimientos funcionales
Estos consisten en las operaciones definidas por el usuario (transacciones) que se aplicaran a la
base de datos.
Para saber cuáles serán nuestros requerimientos funcionales debemos preguntarnos ¿Qué es lo
que queremos solucionar? Identificar el problema, para el ejemplo del video club establecemos
que se necesita almacenar la información. Que es que el sistema debe hacer, ¿Almacenar
información? ¿Generar reportes? Estos ejemplos son los más comunes a la hora de identificar
nuestros requerimientos funcionales.
Tal como se muestra en la siguiente ilustración, en el cual se plantea los posible requerimientos
funcionales que requiere la base de datos de un Video Club.
NO SON REQUERIMIENTOS FUNCIONALES
Estos son ejemplos de requerimientos no funcionales, es decir requerimientos aislados que no
dependen del sistema y en teoría no deben afectar la performance de este. Son requerimientos
que se toman en cuenta pero que no son prioridad.
El segundo principio menciona que es importante que la información sea correcta y completa. Si
la base de datos contiene información incorrecta, los informes que se recogen contendrán
información incorrecta y por lo tanto las decisiones que se tomen estarían mal fundamentadas