Professional Documents
Culture Documents
En la informtica, un modelo de datos es un lenguaje utilizado para la descripcin de una base de datos. Por lo general, un modelo de datos permite describir las estructuras de datos de la base (el tipo de los datos que incluye la base y la forma en que se relacionan), las restricciones de integridad (las condiciones que los datos deben cumplir para reflejar correctamente la realidad deseada) y las operaciones de manipulacin de los datos (agregado, borrado, modificacin y recuperacin de los datos de la base). Se puede definir tambin que un modelo de datos de datos es una coleccin de conceptos que se emplean para describir la estructura de una base de datos, esa coleccin de conceptos incluye entidades, atributos y relaciones, en si un modelado de datos en un lenguaje orientado a describir una Base de datos La mayora de los modelos de datos poseen un conjunto de operaciones bsicas para especificar consultas y actualizaciones de la base de datos. En un enfoque ms amplio, un modelo de datos permite describir los elementos que intervienen en una realidad o en un problema dado y la forma en que se relacionan dichos elementos entre s. Otro enfoque es pensar que un modelo de datos permite describir los elementos de la realidad que intervienen en un problema dado y la forma en que se relacionan esos elementos entre s. Existen diferentes conceptos muy importantes sobre este tema entre los ms destacados tenemos los siguientes: De acuerdo a Ullman.- Un modelo de datos es un sistema formal y abstracto que permite describir los datos de acuerdo con reglas y convenios predefinidos. Es formal pues los objetos del sistema se manipulan siguiendo reglas perfectamente definidas y utilizando exclusivamente los operadores definidos en el sistema, independientemente de lo que estos objetos y operadores puedan significar. Segn Codd.- Un modelo de datos es una combinacin de tres componentes: 1. Una coleccin de estructuras de datos (los bloques constructores de cualquier base de datos que conforman el modelo); 2. Una coleccin de operadores o reglas de inferencia, los cuales pueden ser aplicados a cualquier instancia de los tipos de datos listados en (1) , para consultar o derivar datos de cualquier parte de estas estructuras en cualquier combinacin deseada; 3. Una coleccin de reglas generales de integridad, las cuales explcita o implcitamente definen un conjunto de estados consistentes --estas reglas algunas veces son expresadas como reglas de insertar-actualizar-borrar. Un modelo de datos puede ser usado de la siguiente manera: como una herramienta para especificar los tipos de datos y la organizacin de los mismos que son permisibles en una base de datos especfica; como una base para el desarrollo de una metodologa general de diseo para las bases de datos; como una base para el desarrollo de familias de lenguajes de alto nivel para manipulacin de consultas ( Query ) y datos; como el elemento clave en el diseo de la arquitectura de un manejador de bases de datos. El primer modelo de datos desarrollado con toda la formalidad que esto implica fue el modelo relacional, en 1969, mucho antes incluso que los modelos jerrquicos y de red De acuerdo a Kroenke.- El modelo de datos es el proceso que implica crear una representacin que tienen los usuarios de los datos Si el modelo de datos representa en forma incorrecta la visin que poseen los usuarios de los datos, encontrarn las
Modelado de Datos
aplicaciones difciles de usar, incompletas y por supuesto en el desarrollo de las bases de datos y sus aplicaciones.
Modelado de Datos
Base de datos relacional.
ste es el modelo ms utilizado en la actualidad para modelar problemas reales y administrar datos dinmicamente.
Modelo de tabla
El modelo de tabla consiste en una serie nica, bidimensional de elementos de datos, donde todos los miembros de una columna dada son asumidos para ser valores similares, y todos los miembros de una fila son asumidos para ser relacionados el uno con el otro. Por ejemplo, columnas para el nombre y la contrasea que podra ser usada como una parte de una base de datos de seguridad de sistema. Cada fila tendra la contrasea especfica asociada con un usuario individual. Las columnas de la tabla a menudo tienen un tipo asociado con ellos, definindolos como datos de carcter, fecha o la informacin de tiempo, nmeros enteros, o nmeros de punto flotante.
Modelo jerrquico
En un modelo jerrquico, los datos son organizados en una estructura parecida a un rbol, implicando un eslabn solo ascendente en cada registro para describir anidar, y un campo de clase para guardar los registros en un orden particular en cada lista de mismo-nivel. Las estructuras jerrquicas fueron usadas extensamente en los primeros sistemas de gestin de datos de unidad central, como el Sistema de Direccin de Informacin (IMS) por la IBM, y ahora describen la estructura de documentos XML. Esta estructura permite un 1:N en una relacin entre dos tipos de datos. Esta estructura es muy eficiente para describir muchas relaciones en el verdadero real; recetas, ndice, ordenamiento de prrafos/versos, alguno anid y clasific la informacin. Sin embargo, la estructura jerrquica es ineficaz para ciertas operaciones de base de datos cuando un camino lleno (a diferencia del eslabn ascendente y el campo de clase) tambin no es incluido para cada registro. Una limitacin del modelo jerrquico es su inhabilidad de representar manera eficiente la redundancia en datos. Los modelos de base de datos " el valor de atributo de entidad " como Caboodle por Swink estn basados en esta estructura. En la relacin Padre-hijo: El hijo slo puede tener un padre pero un padre puede tener mltiples hijos. Los padres e hijos son atados juntos por eslabones "indicadores" llamados. Un padre tendr una lista de indicadores de cada uno de sus hijos.
Modelo de red
El modelo de red (definido por la especificacin CODASYL) organiza datos que usan dos fundamental construcciones, registros llamados y conjuntos. Los registros contienen campos (que puede ser organizado jerrquicamente, como en el lenguaje COBOL de lenguaje de programacin). Los conjuntos (para no ser confundido con conjuntos matemticos) definen de
Modelado de Datos
uno a varias relaciones entre registros: un propietario, muchos miembros. Un registro puede ser un propietario en cualquier nmero de conjuntos, y un miembro en cualquier nmero de conjuntos. El modelo de red es una variacin sobre el modelo jerrquico, al grado que es construido sobre el concepto de mltiples ramas (estructuras de nivel inferior) emanando de uno o varios nodos (estructuras de nivel alto), mientras el modelo se diferencia del modelo jerrquico en esto las ramas pueden estar unidas a mltiples nodos. El modelo de red es capaz de representar la redundancia en datos de una manera ms eficiente que en el modelo jerrquico. Las operaciones del modelo de red son de navegacin en el estilo: un programa mantiene una posicin corriente, y navega de un registro al otro por siguiente las relaciones en las cuales el registro participa. Los registros tambin pueden ser localizados por suministrando valores claves. Aunque esto no sea un rasgo esencial del modelo, las bases de datos de red generalmente ponen en prctica las relaciones de juego mediante indicadores que directamente dirigen la ubicacin de un registro sobre el disco. Esto da el funcionamiento de recuperacin excelente, a cargo de operaciones como la carga de base de datos y la reorganizacin. La mayor parte de bases de datos de objeto usan el concepto de navegacin para proporcionar la navegacin rpida a travs de las redes de objetos, generalmente usando identificadores de objeto como indicadores "inteligentes" de objetos relacionados. Objectivity/DB, por ejemplo, los instrumentos llamados 1:1, 1: muchos, muchos: 1 y muchos: muchos, llamados relaciones que pueden cruzar bases de datos. Muchas bases de datos de objeto tambin apoyan SQL, combinando las fuerzas de ambos modelos. El modelo de red (definido por la especificacin CODASYL) organiza datos que usan dos fundamental construcciones, registros llamados y conjuntos. Los registros contienen campos (que puede ser organizado jerrquicamente, como en el lenguaje COBOL de lenguaje de programacin). Los conjuntos (para no ser confundido con conjuntos matemticos) definen de uno a varias relaciones entre registros: un propietario, muchos miembros. Un registro puede ser un propietario en cualquier nmero de conjuntos, y un miembro en cualquier nmero de conjuntos. El modelo de red es una variacin sobre el modelo jerrquico, al grado que es construido sobre el concepto de mltiples ramas (estructuras de nivel inferior) emanando de uno o varios nodos (estructuras de nivel alto), mientras el modelo se diferencia del modelo jerrquico en esto las ramas pueden estar unidas a mltiples nodos. El modelo de red es capaz de representar la redundancia en datos de una manera ms eficiente que en el modelo jerrquico. Las operaciones del modelo de red son de navegacin en el estilo: un programa mantiene una posicin corriente, y navega de un registro al otro por siguiente las relaciones en las cuales el registro participa. Los registros tambin pueden ser localizados por suministrando valores claves. Aunque esto no sea un rasgo esencial del modelo, las bases de datos de red generalmente ponen en prctica las relaciones de juego mediante indicadores que directamente. Dirigen la ubicacin de un registro sobre el disco. Esto da el funcionamiento de recuperacin excelente, a cargo de operaciones como la carga de base de datos y la reorganizacin. La mayor parte de bases de datos de objeto usan el concepto de navegacin para proporcionar la navegacin rpida a travs de las redes de objetos, generalmente usando identificadores de objeto como indicadores "inteligentes" de objetos relacionados. Objectivity/DB, por ejemplo, los instrumentos llamados 1:1, 1: muchos, muchos: 1 y muchos: muchos, llamados relaciones que pueden cruzar bases de datos. Muchas bases de datos de objeto tambin apoyan SQL, combinando las fuerzas de ambos modelos.
El modelo dimensional
Es una adaptacin especializada del modelo relacional, sola representar datos en depsitos de datos, en un camino que los datos fcilmente pueden ser resumidos usando consultas OLAP. En el modelo dimensional, una base de datos consiste en una sola tabla grande de hechos que son descritos usando dimensiones y medidas.
Modelado de Datos
Una dimensin proporciona el contexto de un hecho (como quien particip, cuando y donde pas, y su tipo). Las dimensiones se toman en cuenta en la formulacin de las consultas para agrupar hechos que estn relacionados. Las dimensiones tienden a ser discretas y son a menudo jerrquicas; por ejemplo, la ubicacin podra incluir el edificio, el estado, y el pas. Una medida es una cantidad que describe el hecho, tales como los ingresos. Es importante que las medidas puedan ser agregados significativamente - por ejemplo, los ingresos provenientes de diferentes lugares pueden sumarse. En una consulta (OLAP), las dimensiones son escogidas y los hechos son agrupados y aadidos juntos para crear un reporte. El modelo dimensional a menudo es puesto en prctica sobre la cima del modelo emparentado que usa un esquema de estrella, consistiendo en una mesa que contiene los hechos y mesas circundantes que contienen las dimensiones. Dimensiones en particular complicadas podran ser representadas usando mltiples mesas, causando un esquema de copo de nieve. Un almacn de datos (data warehouse) puede contener mltiples esquemas de estrella que comparten tablas de dimensin, permitindoles para ser usadas juntas. La llegada levanta un conjunto de dimensiones estndar y es una parte importante del modelado dimensional.
Modelo de objeto
En aos recientes, el paradigma mediante objetos ha sido aplicado a la tecnologa de base de datos, creando un nuevo modelo de programa sabido (conocido) como bases de datos de objeto. Estas bases de datos intentan traer el mundo de base de datos y el uso que programa el mundo ms cerca juntos, en particular por asegurando que la base de datos usa el mismo sistema de tipo que el programa de uso. Esto apunta para evitar el elevado (a veces mencionaba el desajuste de impedancia) de convertir la informacin entre su representacin en la base de datos (por ejemplo como filas en mesas) y su representacin en el programa de uso (tpicamente como objetos). Al mismo tiempo, las bases de datos de objeto intentan introducir las ideas claves de programa de objeto, como encapsulacin y polimorfismo, en el mundo de bases de datos. Una variedad de estas formas ha sido aspirada almacenando objetos en una base de datos. Algunos productos se han acercado al problema del uso que programa el final, por haciendo los objetos manipulados segn el programa persistente. Esto tambin tpicamente requiere la adicin de una especie de lengua de pregunta, ya que lenguajes de programacin convencionales no tienen la capacidad de encontrar objetos basados en su contenido de la informacin. Los otros han atacado el problema a partir del final de base de datos, por definiendo un modelo de datos mediante objetos para la base de datos, y definiendo un lenguaje de programacin de base de datos que permite a capacidades de programa llenas as como instalaciones de pregunta tradicionales. Las bases de datos de objeto han sufrido debido a la carencia de estandarizacin: aunque las normas fueran definidas por ODMG, nunca fueron puestas en prctica lo bastante bien para asegurar la interoperabilidad entre productos. Sin embargo, las bases de datos de objeto han sido usadas satisfactoriamente en muchos usos: Usualmente aplicaciones especializadas como bases de datos de ingeniera, base de datos biolgica molecular, ms bien que proceso de datos establecido comercial. Sin embargo, las ideas de base de datos de objeto fueron recogidas por los vendedores emparentados y extensiones influidas hechas a estos productos y de verdad a la lengua SQL.
Modelado de Datos
Modelos de Datos Conceptuales
Son los orientados a la descripcin de estructuras de datos y restricciones de integridad. Se usan fundamentalmente durante la etapa de Anlisis de un problema dado y estn orientados a representar los elementos que intervienen en ese problema y sus relaciones. El ejemplo ms tpico es el Modelo Entidad-Relacin. En el diseo de bases de datos se usan primero los modelos conceptuales para lograr una descripcin de alto nivel de la realidad, y luego se transforma el esquema conceptual en un esquema lgico. El motivo de realizar estas dos etapas es la dificultad de abstraer la estructura de una base de datos que presente cierta complejidad. Un esquema es un conjunto de representaciones lingsticas o grficas que describen la estructura de los datos de inters. Los modelos conceptuales deben ser buenas herramientas para representar la realidad, por lo que deben poseer las siguientes cualidades: Expresividad: deben tener suficientes conceptos para expresar perfectamente la realidad. Simplicidad: deben ser simples para que los esquemas sean fciles de entender. Minimalidad: cada concepto debe tener un significado distinto. Formalidad: todos los conceptos deben tener una interpretacin nica, precisa y bien definida. En general, un modelo no es capaz de expresar todas las propiedades de una realidad determinada, por lo que hay que aadir aserciones que complementen el esquema. Existen distintos tipos de modelos conceptuales:
Basados en registros
Jerrquico: datos en registros, relacionados con apuntadores y organizados como colecciones de rboles Redes: datos en registros relacionados por apuntadores y organizados en grficas arbitrarias Relacional: datos en tablas relacionados por el contenido de ciertas columnas
Basados en objetos
Orientado a objetos: datos como instancias de objetos (incluyendo sus mtodos) Entidad-relacin: datos organizados en conjuntos interrelacionados de objetos (entidades) con atributos asociados
Modelado de Datos
La estructura lgica general de una base de datos puede expresarse grficamente por medio de un diagrama entidad - relacin que consta de los siguientes componentes: Rectngulos, que representan conjuntos de entidades. Elipses, que representan atributos. Rombos, que representan relaciones entre conjuntos de entidades. Lneas, que conectan los atributos a los conjuntos de entidades y los conjuntos de entidades a las relaciones.
objetos.
Relacin Cardinalidad
Ejemplo:
Cardinalidad.-
(Muchos a Muchos)
(Uno a Muchos)
Modelado de Datos
(Uno a Uno) Modelos lgicos basados en registros.- Se utilizan para describir los datos en los niveles conceptual y de visin. A diferencia de los modelos de datos basados en objetos, estos modelos sirven para especificar tanto la estructura lgica general de la base de datos como una descripcin en un nivel ms alto de la implantacin. Modelos de Datos Fsicos Los modelos fsicos sirven para describir los datos en el nivel ms bajo. Ejemplos tpicos de estas estructuras son los rboles B+, las estructuras de Hash, etc. A diferencia de los modelos lgicos de los datos, son muy pocos los modelos fsicos utilizados. Algunos de los ms conocidos son: El modelo unificador La memoria de cuadros
Modelado de Datos
El modelo de datos
Se har una descripcin de la estructura de tablas y columnas para almacenar la informacin de este proceso. Primero, algunas generalidades sobre cmo crear los campos. La clave primaria de las tablas siempre es un identificador autoincrementar. Todas las tablas tienen as un identificador interno, mantenido por el sistema. As, las claves ajenas son ms fciles de mantener. En general, nosotros no solemos poner campos requeridos preferimos hacer la gestin dentro de la lgica de negocio. Nunca se sabe lo que te vas a encontrar, y se nos han dado casos de campos de los que estbamos completamente seguros que eran requeridos y hemos tenido que quitar la marca. No se duplica informacin. Es decir, una de las reglas bsica es que la misma informacin no puede estar en dos sitios, salvo En muchos casos, creamos campos calculados, que permiten acceder de forma rpida a informacin 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 clculo cada vez que nos hace falta ralentiza el funcionamiento del sistema, hacemos un campo calculado que se mantiene automticamente (en nuestro caso, a travs de Triggers de la base de datos). La informacin est duplicada en dos sitios, s, pero por motivos de rendimiento (y siempre est sincronizada). 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 dnde vas a tener que acceder. Descripcin de las entidades El primer paso para hacer el modelo de datos es identificar las entidades (tablas) que vamos a tener. Segn 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 catlogo 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 tambin). 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 ms complejo que el que voy a describir aqu en un artculo posterior lo describir en detalle. Clientes: el que paga puede ser el mismo que el alumno, pero tambin puede que no. Medios de pago: Contiene los diferentes mtodos que los clientes pueden usar para pagar (contado, domiciliacin bancaria, etc.), incluyendo las cuentas bancarias del cliente. Alumnos: la gente que va a clase. Los clientes pueden ser empresas (personas jurdicas), los alumnos son personas fsicas. Un mismo cliente puede tener mltiples alumnos. Matrculas: Refleja en qu curso nos matriculamos, las fechas, la forma de pago, etc. De forma fsica, 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).
Modelado de Datos
Con PK se marcan las claves primarias, y con FK, las claves ajenas algunas lneas se cruzan, no lo puedo evitar. Las flechas indican que una tabla es hija de otra, con la punta de flecha apuntando al padre. Campos para las entidades Slo describir los campos ms importantes, y no incluir los campos de clave primaria y ajena que se describen en el grfico.
Cursos
nombre: varchar(100) descripcion: Memo. Se utilizar, en el contrato que se imprime para el cliente, para hacer una descripcin 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 tipologas, distintos campos memos, 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
10
Modelado de Datos
numero_meses: integer. El nmero de meses de cada recibo. Si es 1, se crear un recibo cada mes mientras dure la matriculacin, si es 3, uno cada tres meses, etc. En algn sistema hemos hecho, en lugar de esto, una estructura de plantillas de recibos, con fechas, descripciones, etc. personalizadas. Eso permite ms flexibilidad y ms control, pero el modelo es bastante ms complejo. numero_orden: integer. A la hora de presentrselo al cliente, poder mostrar primero las que ms nos interesen. importe_matricula: float. Si adems del importe del curso hay un importe de matrcula, se marca aqu. concepto_matricula. El concepto del recibo de matrcula, si creamos uno.
Grupos
nombre: varchar(100) codigo: varchar(20). Siempre viene bien tener una codificacin adems del nombre. Por ejemplo, en algunos sistemas lo utilizamos para guardar el cdigo del grupo en la Fundacin Tripartita. fecha_inicio: date fecha_fin: date. Por defecto, las del curso al que pertenece el grupo, y adems estas fechas no pueden estar fuera de las fechas del curso al que pertenecen. lugar: varchar(100) de imparticin del grupo. En general, hacemos una gestin de aulas, pero eso lo ampliar en otro artculo. 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. Mximo nmero de alumnos permitidos en el grupo. numero_alumnos: Integer. Es el nmero de alumnos existentes en el grupo. Este campo es de slo lectura para el usuario, y es calculado, a travs de una serie de Triggers en la base de datos, para poder saber rpidamente el nmero 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 cdigo, no en la base) que tenemos. As, el usuario puede dar de alta el registro aunque no tenga todos los datos, y volver despus. 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 rpida el conjunto Nombre+ +primer_apellido+ +segundo_apellido direccion: memo codigo_postal: varchar(20): no hay que ser tacao de vez en cuando hay que meter una direccin extranjera y el cdigo postal puede ser ms grande. poblacion: varchar(50) notas_internas: memo etc. de datos personales (profesin, telfonos, email, etc.)
Alumnos
nombre: varchar(100). Lo mismo que en clientes, pero lo requerido es nombre y primer apellido (en clientes es slo nombre por si primer_apellido: varchar(100) segundo_apellido: varchar(100) nombre_completo: varchar(300):
11
Modelado de Datos
etc. de datos personales (profesin, telfonos, 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 informacin 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.
Matrculas
Adems 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, ingls y francs el ingls lo paga el padre y el francs la madre. As, es necesario que cada matrcula est asociada con el alumno, y tambin con el cliente), necesitamos los siguientes campos: fecha_inicio: date. fecha_fin: date. Por defecto, las del curso, pero hay gente que puede matricularse despus o terminar antes (si se da de baja, por ejemplo). importe: real. Por defecto, el de la forma de pago escogida, pero puede ser tambin 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 estadsticas de nmero 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 slo lectura, actualizado a travs de triggers, que permite acceder a la informacin 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, taln, etc. Alumnos en grupos fecha_inicio: date
12
Modelado de Datos
fecha_fin: date. Suele ser una interseccin entre la duracin del grupo y la de la matrcula, pero cuando el alumno cambia de grupo, para una matrcula puede haber varios registros de alumnos en grupos. Hay que tener en cuenta tambin la posibilidad de que en un mismo curso, pagando ms, un alumno pueda asistir a varios grupos (esto tambin lo he visto). Triggers y procedimientos almacenados El modelo de datos y la lgica del negocio estn 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 lgica de negocio asociados con la base de datos, tanto por motivos de organizacin del cdigo como por motivos de rendimiento (un procedimiento almacenado es varios rdenes de magnitud ms rpido que hacer el mismo proceso a travs de un lenguaje de programacin). En el ejemplo que estoy describiendo, hay varios triggers y procedimientos que se usan: Actualizacin 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. Actualizacin 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 creacin de la matrcula (o un trigger AFTER INSERT), que crea los recibos de la matrcula en base al importe y forma de pago seleccionadas.
13