SlideShare una empresa de Scribd logo
Modelo entidad-relación, un ejemplo
práctico (I. Matriculación)
En el desarrollo de software para empresas, el almacenamiento de la
información de un modo organizado es fundamental, la mayoría de los
casos en los que el programador contesta “no se puede hacer” a un
requerimiento de un cliente se debe a un error en el modelado de la
base de datos que funciona como soporte a la aplicación. Ejemplo
práctico, un buen modelado de datos: la gestión de matriculación de
los alumnos, incluyendo los recibos que tienen que pagar, y el pago
parcial de los mismos. Se explica el funcionamiento del proceso (para
que podamos hacer el seguimiento de la implementación), las tablas
que usamos y los campos (de forma resumida) que componen cada
una de las tablas. Idea de los índices, procedimientos almacenados y
triggers que nos pueden resultar útiles para que el rendimiento de la
base de datos sea bueno.


Descripción del proceso de matriculación
(el caso de uso)
Vamos a imaginarnos que nos encontramos en una academia de
idiomas, en la que los alumnos se matriculan y asisten a clase de forma
temporal. En este caso me voy a centrar en lo que se llaman “grupos
abiertos”, es decir, grupos en los que cualquiera se puede matricular (en
oposición a los grupos de empresa o grupos cerrados, que suelen
funcionar de forma diferente).

Cuando llegamos a la academia, se nos ofrece un folleto o catálogo
de productos y servicios, en el que se detallan los diferentes cursos en los
que nos podemos matricular, y las diferentes formas de pago que
podemos utilizar. Seleccionamos uno de los cursos, la forma de pago
que más nos conviene, el horario al que vamos a asistir, y con esta
información nos matriculamos. Como forma de pago, en este caso,
vamos a utilizar un pago mensual, y queremos que se nos domicilie el
pago a través de nuestra cuenta bancaria.

En la academia, llegado este punto, introducen en su sistema de
información nuestros datos y nos imprimen el contrato de prestación de
servicios, en el que se incluyen todos nuestros datos, el curso en el que
nos hemos matriculado y todos los pagos que vamos a tener que
realizar mientras estemos matriculados. Nos piden, de paso, que
paguemos una reserva de plaza, que es una pequeña cantidad del
primer recibo.
En el siguiente día de clase, nos presentamos, y el profesor comprueba
en su hoja de asistencia que estamos incluidos en el grupo… nos da la
bienvenida, y empezamos a estudiar.


El modelo de datos
A partir de aquí haré una descripción de la estructura de tablas y
columnas para almacenar la información de este proceso. Primero,
algunas generalidades sobre cómo crear los campos.

Generalidades
Hay algunas cosas básicas a la hora de modelizar el modelo de datos
que usamos como convenciones (nomenclatura, cosas así). Por
ejemplo:

   1. La clave primaria de las tablas siempre es un identificador
      autoincremental. Todas las tablas tienen así un identificador
      interno, mantenido por el sistema. Así, las claves ajenas son más
      fáciles de mantener.
   2. En general, nosotros no solemos poner campos requeridos…
      preferimos hacer la gestión dentro de la lógica de negocio.
      Nunca se sabe lo que te vas a encontrar, y se nos han dado casos
      de campos de los que estábamos completamente seguros que
      eran requeridos y hemos tenido que quitar la marca.
   3. No se duplica información. Es decir, una de las reglas básica es
      que la misma información no puede estar en dos sitios, salvo…
   4. En muchos casos, creamos campos calculados, que permiten
      acceder de forma rápida a información… por ejemplo, el importe
      pendiente de un recibo, en realidad, se calcula como el importe
      total del recibo menos la suma de los pagos parciales… como
      hacer este cálculo cada vez que nos hace falta ralentiza el
      funcionamiento del sistema, hacemos un campo calculado que
      se mantiene automáticamente (en nuestro caso, a través de
      Triggers de la base de datos). La información está duplicada en
      dos sitios, sí, pero por motivos de rendimiento (y siempre está
      sincronizada).
   5. En los nombres de los campos no ponemos caracteres especiales
      (ni acentos, ni espacios, etc.). Aunque el gestor de base de datos
      lo admita, no lo hacemos, porque luego nunca se sabe desde
      dónde vas a tener que acceder.

Descripción de las entidades
El primer paso para hacer el modelo de datos es identificar las
entidades (tablas) que vamos a tener. Según el caso de uso descrito, las
tablas necesarias son las siguientes (al menos, son las que nosotros
usamos):

      Cursos: almacena la oferta formativa del centro. Representa el
      catálogo o folleto que te dan al llegar al centro.
      Formas de Pago: para cada curso, las distintas opciones de pago
      que existen (es parte del folleto también). Trimestral, mensual,
      anual, etc.
      Grupos: dentro de cada curso, los diferentes horarios a los que se
      puede asistir. En este caso, el modelo que utilizamos es bastante
      más complejo que el que voy a describir aquí… en un artículo
      posterior lo describiré en detalle.
      Clientes: el que paga… puede ser el mismo que el alumno, pero
      también puede que no.
      Medios de pago: Contiene los diferentes métodos que los clientes
      pueden usar para pagar (contado, domicilación bancaria, etc),
      incluyendo las cuentas bancarias del cliente.
      Alumnos: la gente que va a clase. Los clientes pueden ser
      empresas (personas jurídicas), los alumnos son personas físicas. Un
      mismo cliente puede tener múltiples alumnos.
      Matrículas: Refleja en qué curso nos matriculamos, las fechas, la
      forma de pago, etc. De forma física, se refleja en el contrato que
      te dan para firmar.
      Recibos: almacena los recibos que el cliente tiene que pagar (o
      ha pagado) en el centro.
      Pagos: esta tabla refleja los pagos que el cliente ha hecho (un
      recibo no necesariamente se paga de una vez). Como antes, la
      gestión de recibos y pagos que hacemos en realidad es más
      compleja de lo que voy a describir aquí. En otro artículo haré una
      descripción más completa.
      Alumnos en grupos: refleja los alumnos que están asignados a los
      distintos grupos. El alumno puede cambiar de grupo, y no
      queremos perder esa información histórica, así que necesitamos
      una tabla para gestionarlo.

Aquí podéis ver el modelo gráficamente:
Con PK se marcan las claves primarias, y con FK, las claves ajenas…
algunas líneas se cruzan, no lo puedo evitar. Las flechas indican que una
tabla es „hija‟ de otra, con la punta de flecha apuntando al padre.

Como podéis ver, sólo están indicados los campos que forman el
modelo de datos… las claves primarias y las claves ajenas, que en
cualquier caso deben estar ocultas al usuario final. En la siguiente
sección describiremos los campos de cada tabla.

Campos para las entidades
Sólo describiré los campos más importantes, y no incluiré los campos de
clave primaria y ajena que se describen en el gráfico.

Cursos

      nombre: varchar(100)
descripcion: Memo. Se utilizará, en el contrato que se imprime
    para el cliente, para hacer una descripción larga del curso en el
    que el alumno se está matriculando. En uno de los sistemas que
    tenemos, en lugar de tener un campo memo, tenemos una tabla
    separada en la que se guardan, por tipologías, distintos campos
    memo, que se imprimen en distintos lugares del contrato.
    fecha_inicio: date
    fecha_fin: date

Formas de pago

    nombre: varchar(100)
    importe: float. Es el importe de cada recibo que se cobrará
    numero_meses: integer. El número de meses de cada recibo. Si es
    1, se creará un recibo cada mes mientras dure la matriculación, si
    es 3, uno cada tres meses, etc. En algún sistema hemos hecho, en
    lugar de esto, una estructura de plantillas de recibos, con fechas,
    descripciones, etc. personalizadas. Eso permite más flexibilidad y
    más control, pero el modelo es bastante más complejo.
    numero_orden: integer. A la hora de presentárselo al cliente,
    poder mostrar primero las que más nos interesen.
    importe_matricula: float. Si además del importe del curso hay un
    importe de matrícula, se marca aquí.
    concepto_matricula. El concepto del recibo de matrícula, si
    creamos uno.

Grupos

    nombre: varchar(100)
    codigo: varchar(20). Siempre viene bien tener una codificación
    además del nombre. Por ejemplo, en algunos sistemas lo
    utilizamos para guardar el código del grupo en la Fundación
    Tripartita.
    fecha_inicio: date
    fecha_fin: date. Por defecto, las del curso al que pertenece el
    grupo, y además estas fechas no pueden estar fuera de las
    fechas del curso al que pertenecen.
    lugar: varchar(100) de impartición del grupo. En general, hacemos
    una gestión de aulas, pero eso lo ampliaré en otro artículo.
    notas: memo, del grupo
    horario: varchar(100) del grupo. En realidad, el horario se trata
    como una tabla por debajo de esta, pero no voy a entrar en
    tanto nivel de detalle ahora.
    maximo_alumnos: Integer. Máximo número de alumnos permitidos
    en el grupo.
    numero_alumnos: Integer. Es el número de alumnos existentes en
    el grupo. Este campo es de sólo lectura para el usuario, y es
calculado, a través de una serie de Triggers en la base de datos,
     para poder saber rápidamente el número de alumnos activos en
     cada grupo sin tener que estar sumando.

Clientes

     nombre: varchar(100). En nuestros sistemas, normalmente, este es
     el único campo requerido (por código, no en la base) que
     tenemos. Así, el usuario puede dar de alta el registro aunque no
     tenga todos los datos, y volver después.
     primer_apellido: varchar(100)
     segundo_apellido: varchar(100)
     nombre_completo: varchar(300): Esto es un campo calculado,
     que se mantiene con Triggers, para poder coger de forma rápida
     el conjunto Nombre+‟ „+primer_apellido+‟ „+segundo_apellido
     direccion: memo
     codigo_postal: varchar(20): no hay que ser tacaño… de vez en
     cuando hay que meter una dirección extranjera y el código
     postal puede ser más grande.
     poblacion: varchar(50)
     notas_internas: memo
     etc. de datos personales (profesión, teléfonos, email, etc.)

Alumnos

     nombre: varchar(100). Lo mismo que en clientes, pero lo requerido
     es nombre y primer apellido (en clientes es sólo nombre por si
     primer_apellido: varchar(100)
     segundo_apellido: varchar(100)
     nombre_completo: varchar(300):
     etc. de datos personales (profesión, teléfonos, email, etc.)

Medios de pago

     tipo_medio: Integer. Normalmente tiene una tabla asociada con
     los tipos de medios de pago, que suelen ser: Sin Pago, Contado,
     Banco
     nombre_titular: varchar(100)
     direccion_titular: memo
     entidad: varchar(4)
     oficina: varchar(4)
     dc: varchar(2)
     numero_cuenta: varchar(10). Si el tipo_medio es banco, entonces
     se tiene que rellenar la información bancaria del cliente.
     por_defecto: boolean. Se suele preguntar el medio de pago, pero
     teniendo uno por defecto, para no tener que rellenarlo siempre.
Normalmente, cada cliente, al crearse, se crea un medio de
      pago “contado”, y se le pone por defecto.

Matrículas

Además de los datos de curso, forma de pago, medio de pago, alumno
y cliente (esto último puede parece redundante, pero no lo es…
podemos tener el caso (yo lo he visto) de un alumno que se matricula
para estudiar, digamos, inglés y francés… el inglés lo paga el padre y el
francés la madre. Así, es necesario que cada matrícula esté asociada
con el alumno, y también con el cliente), necesitamos los siguientes
campos:

      fecha_inicio: date.
      fecha_fin: date. Por defecto, las del curso, pero hay gente que
      puede matricularse después o terminar antes (si se da de baja,
      por ejemplo).
      importe: real. Por defecto, el de la forma de pago escogida, pero
      puede ser también distinto… descuentos por familiares, cosas así.
      Suele ser buena idea dejarlo abierto, para que el cliente lo pueda
      cambiar.
      motivo_baja: varchar(100). Normalmente, los motivos de baja son
      una tabla separada, para luego poder obtener estadísticas de
      número de bajas por tipo, cosas así.

Recibos

      fecha_emision: date
      fecha_cobro_completo: date
      numero_recibo: varchar(20)
      concepto: varchar(50)
      importe_recibo: float.
      importe_pendiente: float. Es un campo de sólo lectura,
      actualizado a través de triggers, que permite acceder a la
      información sin tener que sumar.

Pagos

      fecha: date
      importe: real
      forma_cobro: varchar(20). Normalmente es una tabla separada,
      igual que el caso de los tipos de baja. Puede ser: contado,
      transferencia, tarjeta, talón, etc.

Alumnos en grupos

      fecha_inicio: date
fecha_fin: date. Suele ser una intersección entre la duración del
        grupo y la de la matrícula, pero cuando el alumno cambia de
        grupo, para una matrícula puede haber varios registros de
        alumnos en grupos. Hay que tener en cuenta también la
        posibilidad de que en un mismo curso, pagando más, un alumno
        pueda asistir a varios grupos (esto también lo he visto).


Triggers y procedimientos almacenados
El modelo de datos y la lógica del negocio están muy estrechamente
relacionados. Los sistemas de base de datos nos permiten desarrollar
triggers y procedimientos almacenados, lo que es muy conveniente
para dejar trozos de la lógica de negocio asociados con la base de
datos, tanto por motivos de organización del código como por motivos
de rendimiento (un procedimiento almacenado es varios órdenes de
magnitud más rápido que hacer el mismo proceso a través de un
lenguaje de programación).

En el ejemplo que estoy describiendo, hay varios triggers y
procedimientos que se usan:

        Actualización de los campos “NombreCompleto” de alumnos y
        clientes: normalmente, es un trigger BEFORE INSERT y BEFORE
        UPDATE, que actualiza el campo en base al contenido del
        nombre y los apellidos.
        Actualización del campo “ImportePagado” de recibos, AFTER
        INSERT, UPDATE y DELETE de pagos, que actualiza el campo
        ImportePendiente de recibos como la suma de los pagos de ese
        recibo.
        Es habitual hacer un procedimiento CREARRECIBOS, que se
        ejecuta en el proceso de creación de la matrícula (o un trigger
        AFTER INSERT), que crea los recibos de la matrícula en base al
        importe y forma de pago seleccionadas.

En las próximas semanas continuaré esta serie de artículos, describiendo
otros submodelos de sistemas que hemos desarrollado… algunas ideas
que tengo:

   1.   Gestión de horarios y citas
   2.   Facturación
   3.   Gestión de horas trabajadas
   4.   Stock
OTRO EJEMPLO

                     EJEMPLO MODELO ENTIDAD-RELACION

    Se desea almacenar la información de una compañía aérea en una B.D
    relacional. La compañía aérea tiene tres recursos principales: Aviones,
    pilotos, tripulación. De cada pila se desea conocer su cod. Nombre y
    horas de vuelo. De los miembros de la tripulación solo se tendrá el cod y
    el nombre. Pilotos y tripulación tienen una base a la que regresan
    después de cada jornada un vuelo va desde un origen a un destino a
    una hora concreta y tiene # de vuelo, de cada vuelo que se va a
    realizar durante los proximos 3 meses, así como de los vuelos que se han
    realizado se desea saber el avion en el que se va a hacer o en el que se
    ha hecho, el piloto y la tripulación.

      Cada avión tiene un cod, es de un tipo (boing, airbus, entre otros). Y
            tiene una base donde es sometido a mantenimiento


.
EJEMPLO MODELO RELACIONAL

Más contenido relacionado

La actualidad más candente

Clase 3 Modelo Entidad Relacion
Clase 3   Modelo Entidad   RelacionClase 3   Modelo Entidad   Relacion
Clase 3 Modelo Entidad Relacion
oswchavez
 
Ejercicios con diagramas modelo Entidad Relacion
Ejercicios con diagramas modelo Entidad RelacionEjercicios con diagramas modelo Entidad Relacion
Ejercicios con diagramas modelo Entidad Relacion
Juan Carlos A. Ch
 
Como Documentar Casos De Uso
Como Documentar Casos De UsoComo Documentar Casos De Uso
Como Documentar Casos De Uso
Universidad Nacional de Frontera
 
Proyecto sistema matriculas
Proyecto sistema matriculasProyecto sistema matriculas
Proyecto sistema matriculas
Wildo Huillca Moyna
 
Modelado Orientado a Objetos
Modelado Orientado a ObjetosModelado Orientado a Objetos
Modelado Orientado a Objetos
Rafael Miranda
 
Del Modelo Entidad-Relación al Modelo relacional
Del Modelo Entidad-Relación al Modelo relacionalDel Modelo Entidad-Relación al Modelo relacional
Del Modelo Entidad-Relación al Modelo relacional
Luis Eduardo Pelaez Valencia
 
Ejercicios en clase Unidad II
Ejercicios en clase Unidad IIEjercicios en clase Unidad II
Ejercicios en clase Unidad II
Luis Caiza
 
Mapa conceptual BD
Mapa conceptual BDMapa conceptual BD
Mapa conceptual BD
Maria Gonzalez
 
Ejercicios de entidad relacion extendida
Ejercicios de entidad relacion extendidaEjercicios de entidad relacion extendida
Ejercicios de entidad relacion extendida
David Rocha Bardales
 
2. Casos de uso y diagramas de casos de uso
2. Casos de uso y diagramas de casos de uso2. Casos de uso y diagramas de casos de uso
2. Casos de uso y diagramas de casos de uso
Saul Mamani
 
Modelo Entidad Relación Extendido.
Modelo Entidad Relación Extendido.Modelo Entidad Relación Extendido.
Modelo Entidad Relación Extendido.
nayis2010
 
diagrama de casos de uso del negocio y del sistema
diagrama de casos de uso del negocio y del sistemadiagrama de casos de uso del negocio y del sistema
diagrama de casos de uso del negocio y del sistema
Universidad Tecnológica
 
22 ejercicios base de datos
22 ejercicios base de datos 22 ejercicios base de datos
22 ejercicios base de datos
Hector Velazquez Alfonso de Castillo
 
Convertir Diagrama Entidad-Relacion a Modelo Relacional.
Convertir Diagrama Entidad-Relacion a Modelo Relacional.Convertir Diagrama Entidad-Relacion a Modelo Relacional.
Convertir Diagrama Entidad-Relacion a Modelo Relacional.
Erivan Martinez Ovando
 
5. Ejercicios normalización
5. Ejercicios normalización5. Ejercicios normalización
5. Ejercicios normalización
Marcelo Herrera
 
Ejercicios del 1 al 9
Ejercicios del 1 al 9Ejercicios del 1 al 9
Ejercicios del 1 al 9
Alessandra Marin
 
Diccionario de datos en los sistemas de información
Diccionario de datos en los sistemas de informaciónDiccionario de datos en los sistemas de información
Diccionario de datos en los sistemas de información
Yaskelly Yedra
 
Etapas en el diseño de Base de Datos
Etapas en el diseño de Base de DatosEtapas en el diseño de Base de Datos
Etapas en el diseño de Base de Datos
Anielka Reyes
 
La importancia de la base de datos
La importancia de la base de datosLa importancia de la base de datos
La importancia de la base de datos
Raul Martinez
 
Ejercicio 2
Ejercicio  2Ejercicio  2
Ejercicio 2
yolymorquecho
 

La actualidad más candente (20)

Clase 3 Modelo Entidad Relacion
Clase 3   Modelo Entidad   RelacionClase 3   Modelo Entidad   Relacion
Clase 3 Modelo Entidad Relacion
 
Ejercicios con diagramas modelo Entidad Relacion
Ejercicios con diagramas modelo Entidad RelacionEjercicios con diagramas modelo Entidad Relacion
Ejercicios con diagramas modelo Entidad Relacion
 
Como Documentar Casos De Uso
Como Documentar Casos De UsoComo Documentar Casos De Uso
Como Documentar Casos De Uso
 
Proyecto sistema matriculas
Proyecto sistema matriculasProyecto sistema matriculas
Proyecto sistema matriculas
 
Modelado Orientado a Objetos
Modelado Orientado a ObjetosModelado Orientado a Objetos
Modelado Orientado a Objetos
 
Del Modelo Entidad-Relación al Modelo relacional
Del Modelo Entidad-Relación al Modelo relacionalDel Modelo Entidad-Relación al Modelo relacional
Del Modelo Entidad-Relación al Modelo relacional
 
Ejercicios en clase Unidad II
Ejercicios en clase Unidad IIEjercicios en clase Unidad II
Ejercicios en clase Unidad II
 
Mapa conceptual BD
Mapa conceptual BDMapa conceptual BD
Mapa conceptual BD
 
Ejercicios de entidad relacion extendida
Ejercicios de entidad relacion extendidaEjercicios de entidad relacion extendida
Ejercicios de entidad relacion extendida
 
2. Casos de uso y diagramas de casos de uso
2. Casos de uso y diagramas de casos de uso2. Casos de uso y diagramas de casos de uso
2. Casos de uso y diagramas de casos de uso
 
Modelo Entidad Relación Extendido.
Modelo Entidad Relación Extendido.Modelo Entidad Relación Extendido.
Modelo Entidad Relación Extendido.
 
diagrama de casos de uso del negocio y del sistema
diagrama de casos de uso del negocio y del sistemadiagrama de casos de uso del negocio y del sistema
diagrama de casos de uso del negocio y del sistema
 
22 ejercicios base de datos
22 ejercicios base de datos 22 ejercicios base de datos
22 ejercicios base de datos
 
Convertir Diagrama Entidad-Relacion a Modelo Relacional.
Convertir Diagrama Entidad-Relacion a Modelo Relacional.Convertir Diagrama Entidad-Relacion a Modelo Relacional.
Convertir Diagrama Entidad-Relacion a Modelo Relacional.
 
5. Ejercicios normalización
5. Ejercicios normalización5. Ejercicios normalización
5. Ejercicios normalización
 
Ejercicios del 1 al 9
Ejercicios del 1 al 9Ejercicios del 1 al 9
Ejercicios del 1 al 9
 
Diccionario de datos en los sistemas de información
Diccionario de datos en los sistemas de informaciónDiccionario de datos en los sistemas de información
Diccionario de datos en los sistemas de información
 
Etapas en el diseño de Base de Datos
Etapas en el diseño de Base de DatosEtapas en el diseño de Base de Datos
Etapas en el diseño de Base de Datos
 
La importancia de la base de datos
La importancia de la base de datosLa importancia de la base de datos
La importancia de la base de datos
 
Ejercicio 2
Ejercicio  2Ejercicio  2
Ejercicio 2
 

Destacado

Diseñar una Base de Datos en Base al Modelo Entidad/Relacion.
Diseñar una Base de Datos en Base al Modelo Entidad/Relacion.Diseñar una Base de Datos en Base al Modelo Entidad/Relacion.
Diseñar una Base de Datos en Base al Modelo Entidad/Relacion.
LizbethBarraza
 
diseñar una base de datos en base al modelo entidad/relación
diseñar una base de datos en base al modelo entidad/relacióndiseñar una base de datos en base al modelo entidad/relación
diseñar una base de datos en base al modelo entidad/relación
elvi Hernandez
 
Modelo entidad relacion
Modelo entidad relacionModelo entidad relacion
Modelo entidad relacion
cristhianmolina19888
 
Proyecto inventario 1
Proyecto inventario 1Proyecto inventario 1
Proyecto inventario 1
Ernesto River Cruz
 
Caso practico de ing. software
Caso practico de ing. softwareCaso practico de ing. software
Caso practico de ing. software
Byrna Carmona
 
Requerimientos de la base de datos
Requerimientos de la base de datosRequerimientos de la base de datos
Requerimientos de la base de datos
manuellinaresb
 
Sql procedimientos-almacenados
Sql procedimientos-almacenadosSql procedimientos-almacenados
Sql procedimientos-almacenados
Jose Miguel Guerrero Montero
 
Modelo relacional
Modelo relacionalModelo relacional
Modelo relacional
Nelson Salinas
 
Bd ferreteria
Bd ferreteriaBd ferreteria
Bd ferreteria
dapaes
 
Vistas en bases de datos
Vistas en bases de datosVistas en bases de datos
Vistas en bases de datos
Denisse C
 
Base de datos modelo entidad relacion
Base de datos modelo entidad relacionBase de datos modelo entidad relacion
Base de datos modelo entidad relacion
Fco Javier Rodriguez
 
Modelo entidad relación de base de datos
Modelo entidad relación de base de datosModelo entidad relación de base de datos
Modelo entidad relación de base de datos
ani_tuza
 
Diseño físico y lógico de los sistemas de informacion
Diseño físico y lógico de los sistemas de informacionDiseño físico y lógico de los sistemas de informacion
Diseño físico y lógico de los sistemas de informacion
YESENIA CETINA
 
Ejemplos de entidad relacion
Ejemplos de entidad relacionEjemplos de entidad relacion
Ejemplos de entidad relacion
Rodrigo Claros Euscate
 

Destacado (14)

Diseñar una Base de Datos en Base al Modelo Entidad/Relacion.
Diseñar una Base de Datos en Base al Modelo Entidad/Relacion.Diseñar una Base de Datos en Base al Modelo Entidad/Relacion.
Diseñar una Base de Datos en Base al Modelo Entidad/Relacion.
 
diseñar una base de datos en base al modelo entidad/relación
diseñar una base de datos en base al modelo entidad/relacióndiseñar una base de datos en base al modelo entidad/relación
diseñar una base de datos en base al modelo entidad/relación
 
Modelo entidad relacion
Modelo entidad relacionModelo entidad relacion
Modelo entidad relacion
 
Proyecto inventario 1
Proyecto inventario 1Proyecto inventario 1
Proyecto inventario 1
 
Caso practico de ing. software
Caso practico de ing. softwareCaso practico de ing. software
Caso practico de ing. software
 
Requerimientos de la base de datos
Requerimientos de la base de datosRequerimientos de la base de datos
Requerimientos de la base de datos
 
Sql procedimientos-almacenados
Sql procedimientos-almacenadosSql procedimientos-almacenados
Sql procedimientos-almacenados
 
Modelo relacional
Modelo relacionalModelo relacional
Modelo relacional
 
Bd ferreteria
Bd ferreteriaBd ferreteria
Bd ferreteria
 
Vistas en bases de datos
Vistas en bases de datosVistas en bases de datos
Vistas en bases de datos
 
Base de datos modelo entidad relacion
Base de datos modelo entidad relacionBase de datos modelo entidad relacion
Base de datos modelo entidad relacion
 
Modelo entidad relación de base de datos
Modelo entidad relación de base de datosModelo entidad relación de base de datos
Modelo entidad relación de base de datos
 
Diseño físico y lógico de los sistemas de informacion
Diseño físico y lógico de los sistemas de informacionDiseño físico y lógico de los sistemas de informacion
Diseño físico y lógico de los sistemas de informacion
 
Ejemplos de entidad relacion
Ejemplos de entidad relacionEjemplos de entidad relacion
Ejemplos de entidad relacion
 

Similar a 1. modelo entidad relacion ejemplo

Jon Cartier
Jon CartierJon Cartier
Jon Cartier
Silver Wolf
 
01 introduccion (1)my sql
01 introduccion (1)my sql01 introduccion (1)my sql
01 introduccion (1)my sql
Marina de Pendragón
 
Introduccion a excel
Introduccion a excelIntroduccion a excel
Introduccion a excel
Christian Mayorga
 
Tipos de bases de datos
Tipos de bases de datosTipos de bases de datos
Tipos de bases de datos
Luis Fernando Ordóñez Armijos
 
Estructuración del blog trabajo grupal
Estructuración del blog   trabajo grupalEstructuración del blog   trabajo grupal
Estructuración del blog trabajo grupal
marianasanchez183
 
herramientas de access
herramientas de accessherramientas de access
herramientas de access
ginnary gómez
 
Capitulo 1 Catherine M. Ricardo
Capitulo 1 Catherine M. RicardoCapitulo 1 Catherine M. Ricardo
Capitulo 1 Catherine M. Ricardo
José Ricardo Tillero Giménez
 
Modelo E-R.pdf
Modelo E-R.pdfModelo E-R.pdf
Modelo E-R.pdf
Maria Garcia
 
Estructuración del blog trabajo grupal (1)
Estructuración del blog   trabajo grupal (1)Estructuración del blog   trabajo grupal (1)
Estructuración del blog trabajo grupal (1)
Andrs124638
 
Verònica capòn
Verònica capònVerònica capòn
Verònica capòn
elizavero
 
Verònica capòn
Verònica capònVerònica capòn
Verònica capòn
veroeliza
 
Verònica capòn
Verònica capònVerònica capòn
Verònica capòn
elizavero
 
Verònica capòn
Verònica capònVerònica capòn
Verònica capòn
elizavero
 
Modelos de análisis estructurado
Modelos de análisis estructuradoModelos de análisis estructurado
Modelos de análisis estructurado
'Jhoan Lamax
 
Dfd
DfdDfd
Elaboración de propuestas de solución de consultoría
Elaboración de propuestas de solución de consultoríaElaboración de propuestas de solución de consultoría
Elaboración de propuestas de solución de consultoría
Christian Alejandro Arroyo Cano
 
Mcvs ad-04 diseño del sistema de información
Mcvs ad-04 diseño del sistema de informaciónMcvs ad-04 diseño del sistema de información
Mcvs ad-04 diseño del sistema de información
giancarlo Aguirre Campos
 
Elementos para solucionar problemas en seudocódigo c4. p1.
Elementos para solucionar problemas en seudocódigo c4. p1.Elementos para solucionar problemas en seudocódigo c4. p1.
Elementos para solucionar problemas en seudocódigo c4. p1.
DENIRAMIREZANDRADE
 
Nuevo presentación de microsoft office power point 97 2003
Nuevo presentación de microsoft office power point 97 2003Nuevo presentación de microsoft office power point 97 2003
Nuevo presentación de microsoft office power point 97 2003
infobran
 
Elementos para solucionar problemas en seudocodigo c4. p1.pptx
Elementos para solucionar problemas en seudocodigo c4. p1.pptxElementos para solucionar problemas en seudocodigo c4. p1.pptx
Elementos para solucionar problemas en seudocodigo c4. p1.pptx
DenRamrezAndrade
 

Similar a 1. modelo entidad relacion ejemplo (20)

Jon Cartier
Jon CartierJon Cartier
Jon Cartier
 
01 introduccion (1)my sql
01 introduccion (1)my sql01 introduccion (1)my sql
01 introduccion (1)my sql
 
Introduccion a excel
Introduccion a excelIntroduccion a excel
Introduccion a excel
 
Tipos de bases de datos
Tipos de bases de datosTipos de bases de datos
Tipos de bases de datos
 
Estructuración del blog trabajo grupal
Estructuración del blog   trabajo grupalEstructuración del blog   trabajo grupal
Estructuración del blog trabajo grupal
 
herramientas de access
herramientas de accessherramientas de access
herramientas de access
 
Capitulo 1 Catherine M. Ricardo
Capitulo 1 Catherine M. RicardoCapitulo 1 Catherine M. Ricardo
Capitulo 1 Catherine M. Ricardo
 
Modelo E-R.pdf
Modelo E-R.pdfModelo E-R.pdf
Modelo E-R.pdf
 
Estructuración del blog trabajo grupal (1)
Estructuración del blog   trabajo grupal (1)Estructuración del blog   trabajo grupal (1)
Estructuración del blog trabajo grupal (1)
 
Verònica capòn
Verònica capònVerònica capòn
Verònica capòn
 
Verònica capòn
Verònica capònVerònica capòn
Verònica capòn
 
Verònica capòn
Verònica capònVerònica capòn
Verònica capòn
 
Verònica capòn
Verònica capònVerònica capòn
Verònica capòn
 
Modelos de análisis estructurado
Modelos de análisis estructuradoModelos de análisis estructurado
Modelos de análisis estructurado
 
Dfd
DfdDfd
Dfd
 
Elaboración de propuestas de solución de consultoría
Elaboración de propuestas de solución de consultoríaElaboración de propuestas de solución de consultoría
Elaboración de propuestas de solución de consultoría
 
Mcvs ad-04 diseño del sistema de información
Mcvs ad-04 diseño del sistema de informaciónMcvs ad-04 diseño del sistema de información
Mcvs ad-04 diseño del sistema de información
 
Elementos para solucionar problemas en seudocódigo c4. p1.
Elementos para solucionar problemas en seudocódigo c4. p1.Elementos para solucionar problemas en seudocódigo c4. p1.
Elementos para solucionar problemas en seudocódigo c4. p1.
 
Nuevo presentación de microsoft office power point 97 2003
Nuevo presentación de microsoft office power point 97 2003Nuevo presentación de microsoft office power point 97 2003
Nuevo presentación de microsoft office power point 97 2003
 
Elementos para solucionar problemas en seudocodigo c4. p1.pptx
Elementos para solucionar problemas en seudocodigo c4. p1.pptxElementos para solucionar problemas en seudocodigo c4. p1.pptx
Elementos para solucionar problemas en seudocodigo c4. p1.pptx
 

Más de univ of pamplona

Entidad relacion
Entidad relacionEntidad relacion
Entidad relacion
univ of pamplona
 
Exposicion unidad 1 ing software
Exposicion unidad 1 ing softwareExposicion unidad 1 ing software
Exposicion unidad 1 ing software
univ of pamplona
 
2. presentacion acis calidad software basado en normas calidad
2. presentacion acis calidad software basado en normas calidad2. presentacion acis calidad software basado en normas calidad
2. presentacion acis calidad software basado en normas calidad
univ of pamplona
 
Arquitectura de una aplicación
Arquitectura de una aplicaciónArquitectura de una aplicación
Arquitectura de una aplicación
univ of pamplona
 
Ejemplo arquitectura 3 capas con access
Ejemplo arquitectura 3 capas con accessEjemplo arquitectura 3 capas con access
Ejemplo arquitectura 3 capas con access
univ of pamplona
 
Arquitectura multicapa
Arquitectura multicapaArquitectura multicapa
Arquitectura multicapa
univ of pamplona
 
4 ppt tema1
4 ppt tema14 ppt tema1
4 ppt tema1
univ of pamplona
 
2. introduccion a la_ing_de_software
2. introduccion a la_ing_de_software2. introduccion a la_ing_de_software
2. introduccion a la_ing_de_software
univ of pamplona
 
1. curso unal cap1
1. curso unal cap11. curso unal cap1
1. curso unal cap1
univ of pamplona
 
1 lectura inicial - que es ingenieria de software
1  lectura inicial - que es ingenieria de software1  lectura inicial - que es ingenieria de software
1 lectura inicial - que es ingenieria de software
univ of pamplona
 
Espe tecnicas siia_2
Espe tecnicas siia_2Espe tecnicas siia_2
Espe tecnicas siia_2
univ of pamplona
 
Entrevistas
EntrevistasEntrevistas
Entrevistas
univ of pamplona
 
2. requerimientos del software
2. requerimientos del software2. requerimientos del software
2. requerimientos del software
univ of pamplona
 
1. curso unal cap1
1. curso unal cap11. curso unal cap1
1. curso unal cap1
univ of pamplona
 

Más de univ of pamplona (14)

Entidad relacion
Entidad relacionEntidad relacion
Entidad relacion
 
Exposicion unidad 1 ing software
Exposicion unidad 1 ing softwareExposicion unidad 1 ing software
Exposicion unidad 1 ing software
 
2. presentacion acis calidad software basado en normas calidad
2. presentacion acis calidad software basado en normas calidad2. presentacion acis calidad software basado en normas calidad
2. presentacion acis calidad software basado en normas calidad
 
Arquitectura de una aplicación
Arquitectura de una aplicaciónArquitectura de una aplicación
Arquitectura de una aplicación
 
Ejemplo arquitectura 3 capas con access
Ejemplo arquitectura 3 capas con accessEjemplo arquitectura 3 capas con access
Ejemplo arquitectura 3 capas con access
 
Arquitectura multicapa
Arquitectura multicapaArquitectura multicapa
Arquitectura multicapa
 
4 ppt tema1
4 ppt tema14 ppt tema1
4 ppt tema1
 
2. introduccion a la_ing_de_software
2. introduccion a la_ing_de_software2. introduccion a la_ing_de_software
2. introduccion a la_ing_de_software
 
1. curso unal cap1
1. curso unal cap11. curso unal cap1
1. curso unal cap1
 
1 lectura inicial - que es ingenieria de software
1  lectura inicial - que es ingenieria de software1  lectura inicial - que es ingenieria de software
1 lectura inicial - que es ingenieria de software
 
Espe tecnicas siia_2
Espe tecnicas siia_2Espe tecnicas siia_2
Espe tecnicas siia_2
 
Entrevistas
EntrevistasEntrevistas
Entrevistas
 
2. requerimientos del software
2. requerimientos del software2. requerimientos del software
2. requerimientos del software
 
1. curso unal cap1
1. curso unal cap11. curso unal cap1
1. curso unal cap1
 

1. modelo entidad relacion ejemplo

  • 1. Modelo entidad-relación, un ejemplo práctico (I. Matriculación) En el desarrollo de software para empresas, el almacenamiento de la información de un modo organizado es fundamental, la mayoría de los casos en los que el programador contesta “no se puede hacer” a un requerimiento de un cliente se debe a un error en el modelado de la base de datos que funciona como soporte a la aplicación. Ejemplo práctico, un buen modelado de datos: la gestión de matriculación de los alumnos, incluyendo los recibos que tienen que pagar, y el pago parcial de los mismos. Se explica el funcionamiento del proceso (para que podamos hacer el seguimiento de la implementación), las tablas que usamos y los campos (de forma resumida) que componen cada una de las tablas. Idea de los índices, procedimientos almacenados y triggers que nos pueden resultar útiles para que el rendimiento de la base de datos sea bueno. Descripción del proceso de matriculación (el caso de uso) Vamos a imaginarnos que nos encontramos en una academia de idiomas, en la que los alumnos se matriculan y asisten a clase de forma temporal. En este caso me voy a centrar en lo que se llaman “grupos abiertos”, es decir, grupos en los que cualquiera se puede matricular (en oposición a los grupos de empresa o grupos cerrados, que suelen funcionar de forma diferente). Cuando llegamos a la academia, se nos ofrece un folleto o catálogo de productos y servicios, en el que se detallan los diferentes cursos en los que nos podemos matricular, y las diferentes formas de pago que podemos utilizar. Seleccionamos uno de los cursos, la forma de pago que más nos conviene, el horario al que vamos a asistir, y con esta información nos matriculamos. Como forma de pago, en este caso, vamos a utilizar un pago mensual, y queremos que se nos domicilie el pago a través de nuestra cuenta bancaria. En la academia, llegado este punto, introducen en su sistema de información nuestros datos y nos imprimen el contrato de prestación de servicios, en el que se incluyen todos nuestros datos, el curso en el que nos hemos matriculado y todos los pagos que vamos a tener que realizar mientras estemos matriculados. Nos piden, de paso, que paguemos una reserva de plaza, que es una pequeña cantidad del primer recibo.
  • 2. En el siguiente día de clase, nos presentamos, y el profesor comprueba en su hoja de asistencia que estamos incluidos en el grupo… nos da la bienvenida, y empezamos a estudiar. El modelo de datos A partir de aquí haré una descripción de la estructura de tablas y columnas para almacenar la información de este proceso. Primero, algunas generalidades sobre cómo crear los campos. Generalidades Hay algunas cosas básicas a la hora de modelizar el modelo de datos que usamos como convenciones (nomenclatura, cosas así). Por ejemplo: 1. La clave primaria de las tablas siempre es un identificador autoincremental. Todas las tablas tienen así un identificador interno, mantenido por el sistema. Así, las claves ajenas son más fáciles de mantener. 2. En general, nosotros no solemos poner campos requeridos… preferimos hacer la gestión dentro de la lógica de negocio. Nunca se sabe lo que te vas a encontrar, y se nos han dado casos de campos de los que estábamos completamente seguros que eran requeridos y hemos tenido que quitar la marca. 3. No se duplica información. Es decir, una de las reglas básica es que la misma información no puede estar en dos sitios, salvo… 4. En muchos casos, creamos campos calculados, que permiten acceder de forma rápida a información… por ejemplo, el importe pendiente de un recibo, en realidad, se calcula como el importe total del recibo menos la suma de los pagos parciales… como hacer este cálculo cada vez que nos hace falta ralentiza el funcionamiento del sistema, hacemos un campo calculado que se mantiene automáticamente (en nuestro caso, a través de Triggers de la base de datos). La información está duplicada en dos sitios, sí, pero por motivos de rendimiento (y siempre está sincronizada). 5. En los nombres de los campos no ponemos caracteres especiales (ni acentos, ni espacios, etc.). Aunque el gestor de base de datos lo admita, no lo hacemos, porque luego nunca se sabe desde dónde vas a tener que acceder. Descripción de las entidades
  • 3. El primer paso para hacer el modelo de datos es identificar las entidades (tablas) que vamos a tener. Según el caso de uso descrito, las tablas necesarias son las siguientes (al menos, son las que nosotros usamos): Cursos: almacena la oferta formativa del centro. Representa el catálogo o folleto que te dan al llegar al centro. Formas de Pago: para cada curso, las distintas opciones de pago que existen (es parte del folleto también). Trimestral, mensual, anual, etc. Grupos: dentro de cada curso, los diferentes horarios a los que se puede asistir. En este caso, el modelo que utilizamos es bastante más complejo que el que voy a describir aquí… en un artículo posterior lo describiré en detalle. Clientes: el que paga… puede ser el mismo que el alumno, pero también puede que no. Medios de pago: Contiene los diferentes métodos que los clientes pueden usar para pagar (contado, domicilación bancaria, etc), incluyendo las cuentas bancarias del cliente. Alumnos: la gente que va a clase. Los clientes pueden ser empresas (personas jurídicas), los alumnos son personas físicas. Un mismo cliente puede tener múltiples alumnos. Matrículas: Refleja en qué curso nos matriculamos, las fechas, la forma de pago, etc. De forma física, se refleja en el contrato que te dan para firmar. Recibos: almacena los recibos que el cliente tiene que pagar (o ha pagado) en el centro. Pagos: esta tabla refleja los pagos que el cliente ha hecho (un recibo no necesariamente se paga de una vez). Como antes, la gestión de recibos y pagos que hacemos en realidad es más compleja de lo que voy a describir aquí. En otro artículo haré una descripción más completa. Alumnos en grupos: refleja los alumnos que están asignados a los distintos grupos. El alumno puede cambiar de grupo, y no queremos perder esa información histórica, así que necesitamos una tabla para gestionarlo. Aquí podéis ver el modelo gráficamente:
  • 4. Con PK se marcan las claves primarias, y con FK, las claves ajenas… algunas líneas se cruzan, no lo puedo evitar. Las flechas indican que una tabla es „hija‟ de otra, con la punta de flecha apuntando al padre. Como podéis ver, sólo están indicados los campos que forman el modelo de datos… las claves primarias y las claves ajenas, que en cualquier caso deben estar ocultas al usuario final. En la siguiente sección describiremos los campos de cada tabla. Campos para las entidades Sólo describiré los campos más importantes, y no incluiré los campos de clave primaria y ajena que se describen en el gráfico. Cursos nombre: varchar(100)
  • 5. descripcion: Memo. Se utilizará, en el contrato que se imprime para el cliente, para hacer una descripción larga del curso en el que el alumno se está matriculando. En uno de los sistemas que tenemos, en lugar de tener un campo memo, tenemos una tabla separada en la que se guardan, por tipologías, distintos campos memo, que se imprimen en distintos lugares del contrato. fecha_inicio: date fecha_fin: date Formas de pago nombre: varchar(100) importe: float. Es el importe de cada recibo que se cobrará numero_meses: integer. El número de meses de cada recibo. Si es 1, se creará un recibo cada mes mientras dure la matriculación, si es 3, uno cada tres meses, etc. En algún sistema hemos hecho, en lugar de esto, una estructura de plantillas de recibos, con fechas, descripciones, etc. personalizadas. Eso permite más flexibilidad y más control, pero el modelo es bastante más complejo. numero_orden: integer. A la hora de presentárselo al cliente, poder mostrar primero las que más nos interesen. importe_matricula: float. Si además del importe del curso hay un importe de matrícula, se marca aquí. concepto_matricula. El concepto del recibo de matrícula, si creamos uno. Grupos nombre: varchar(100) codigo: varchar(20). Siempre viene bien tener una codificación además del nombre. Por ejemplo, en algunos sistemas lo utilizamos para guardar el código del grupo en la Fundación Tripartita. fecha_inicio: date fecha_fin: date. Por defecto, las del curso al que pertenece el grupo, y además estas fechas no pueden estar fuera de las fechas del curso al que pertenecen. lugar: varchar(100) de impartición del grupo. En general, hacemos una gestión de aulas, pero eso lo ampliaré en otro artículo. notas: memo, del grupo horario: varchar(100) del grupo. En realidad, el horario se trata como una tabla por debajo de esta, pero no voy a entrar en tanto nivel de detalle ahora. maximo_alumnos: Integer. Máximo número de alumnos permitidos en el grupo. numero_alumnos: Integer. Es el número de alumnos existentes en el grupo. Este campo es de sólo lectura para el usuario, y es
  • 6. calculado, a través de una serie de Triggers en la base de datos, para poder saber rápidamente el número de alumnos activos en cada grupo sin tener que estar sumando. Clientes nombre: varchar(100). En nuestros sistemas, normalmente, este es el único campo requerido (por código, no en la base) que tenemos. Así, el usuario puede dar de alta el registro aunque no tenga todos los datos, y volver después. primer_apellido: varchar(100) segundo_apellido: varchar(100) nombre_completo: varchar(300): Esto es un campo calculado, que se mantiene con Triggers, para poder coger de forma rápida el conjunto Nombre+‟ „+primer_apellido+‟ „+segundo_apellido direccion: memo codigo_postal: varchar(20): no hay que ser tacaño… de vez en cuando hay que meter una dirección extranjera y el código postal puede ser más grande. poblacion: varchar(50) notas_internas: memo etc. de datos personales (profesión, teléfonos, email, etc.) Alumnos nombre: varchar(100). Lo mismo que en clientes, pero lo requerido es nombre y primer apellido (en clientes es sólo nombre por si primer_apellido: varchar(100) segundo_apellido: varchar(100) nombre_completo: varchar(300): etc. de datos personales (profesión, teléfonos, email, etc.) Medios de pago tipo_medio: Integer. Normalmente tiene una tabla asociada con los tipos de medios de pago, que suelen ser: Sin Pago, Contado, Banco nombre_titular: varchar(100) direccion_titular: memo entidad: varchar(4) oficina: varchar(4) dc: varchar(2) numero_cuenta: varchar(10). Si el tipo_medio es banco, entonces se tiene que rellenar la información bancaria del cliente. por_defecto: boolean. Se suele preguntar el medio de pago, pero teniendo uno por defecto, para no tener que rellenarlo siempre.
  • 7. Normalmente, cada cliente, al crearse, se crea un medio de pago “contado”, y se le pone por defecto. Matrículas Además de los datos de curso, forma de pago, medio de pago, alumno y cliente (esto último puede parece redundante, pero no lo es… podemos tener el caso (yo lo he visto) de un alumno que se matricula para estudiar, digamos, inglés y francés… el inglés lo paga el padre y el francés la madre. Así, es necesario que cada matrícula esté asociada con el alumno, y también con el cliente), necesitamos los siguientes campos: fecha_inicio: date. fecha_fin: date. Por defecto, las del curso, pero hay gente que puede matricularse después o terminar antes (si se da de baja, por ejemplo). importe: real. Por defecto, el de la forma de pago escogida, pero puede ser también distinto… descuentos por familiares, cosas así. Suele ser buena idea dejarlo abierto, para que el cliente lo pueda cambiar. motivo_baja: varchar(100). Normalmente, los motivos de baja son una tabla separada, para luego poder obtener estadísticas de número de bajas por tipo, cosas así. Recibos fecha_emision: date fecha_cobro_completo: date numero_recibo: varchar(20) concepto: varchar(50) importe_recibo: float. importe_pendiente: float. Es un campo de sólo lectura, actualizado a través de triggers, que permite acceder a la información sin tener que sumar. Pagos fecha: date importe: real forma_cobro: varchar(20). Normalmente es una tabla separada, igual que el caso de los tipos de baja. Puede ser: contado, transferencia, tarjeta, talón, etc. Alumnos en grupos fecha_inicio: date
  • 8. fecha_fin: date. Suele ser una intersección entre la duración del grupo y la de la matrícula, pero cuando el alumno cambia de grupo, para una matrícula puede haber varios registros de alumnos en grupos. Hay que tener en cuenta también la posibilidad de que en un mismo curso, pagando más, un alumno pueda asistir a varios grupos (esto también lo he visto). Triggers y procedimientos almacenados El modelo de datos y la lógica del negocio están muy estrechamente relacionados. Los sistemas de base de datos nos permiten desarrollar triggers y procedimientos almacenados, lo que es muy conveniente para dejar trozos de la lógica de negocio asociados con la base de datos, tanto por motivos de organización del código como por motivos de rendimiento (un procedimiento almacenado es varios órdenes de magnitud más rápido que hacer el mismo proceso a través de un lenguaje de programación). En el ejemplo que estoy describiendo, hay varios triggers y procedimientos que se usan: Actualización de los campos “NombreCompleto” de alumnos y clientes: normalmente, es un trigger BEFORE INSERT y BEFORE UPDATE, que actualiza el campo en base al contenido del nombre y los apellidos. Actualización del campo “ImportePagado” de recibos, AFTER INSERT, UPDATE y DELETE de pagos, que actualiza el campo ImportePendiente de recibos como la suma de los pagos de ese recibo. Es habitual hacer un procedimiento CREARRECIBOS, que se ejecuta en el proceso de creación de la matrícula (o un trigger AFTER INSERT), que crea los recibos de la matrícula en base al importe y forma de pago seleccionadas. En las próximas semanas continuaré esta serie de artículos, describiendo otros submodelos de sistemas que hemos desarrollado… algunas ideas que tengo: 1. Gestión de horarios y citas 2. Facturación 3. Gestión de horas trabajadas 4. Stock
  • 9. OTRO EJEMPLO EJEMPLO MODELO ENTIDAD-RELACION Se desea almacenar la información de una compañía aérea en una B.D relacional. La compañía aérea tiene tres recursos principales: Aviones, pilotos, tripulación. De cada pila se desea conocer su cod. Nombre y horas de vuelo. De los miembros de la tripulación solo se tendrá el cod y el nombre. Pilotos y tripulación tienen una base a la que regresan después de cada jornada un vuelo va desde un origen a un destino a una hora concreta y tiene # de vuelo, de cada vuelo que se va a realizar durante los proximos 3 meses, así como de los vuelos que se han realizado se desea saber el avion en el que se va a hacer o en el que se ha hecho, el piloto y la tripulación. Cada avión tiene un cod, es de un tipo (boing, airbus, entre otros). Y tiene una base donde es sometido a mantenimiento .