You are on page 1of 13

Modelado de Datos

1.- Qu es un modelado de datos

Investigacin Punto Net

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

Investigacin Punto Net

aplicaciones difciles de usar, incompletas y por supuesto en el desarrollo de las bases de datos y sus aplicaciones.

2.- Sub Lenguajes de un modelado de datos


Por lo general, un modelo de datos presenta dos sub lenguajes: Lenguaje de Definicin de Datos o DDL (Data Definition Language), cuya funcin es describir, de una forma abstracta, las estructuras de datos y las restricciones de integridad. Lenguaje de Manipulacin de Datos o DML (Data Manipulation Language), que se orienta a describir las operaciones de manipulacin de los datos. A la parte del DML enfocada a la recuperacin de datos, se la suele conocer como Lenguaje de Consulta o QL (Query Language). No hay que perder de vista que una Base de Datos siempre est orientada a resolver un problema determinado, por lo que los dos enfoques propuestos son necesarios en cualquier desarrollo de software.

3.- Caractersticas de un modelado de datos


Es el proceso de analizar los aspectos de inters para una organizacin y la relacin que tienen unos con otros. Resulta en el descubrimiento y documentacin de los recursos de datos del negocio. l modelado hace la pregunta " Qu? " en lugar de " Cmo? ", sta ltima orientada al procesamiento de los datos. Es una tarea difcil, bastante difcil, pero es una actividad necesaria cuya habilidad solo se adquiere con la experiencia.

4.- Metas y Beneficios de un modelado de datos


Registrar los requerimientos de datos de un proceso de negocio. Dicho proceso puede ser demasiado complejo y se tendr que crear un "enterprise data model", el cual deber estar constituido de lneas individuales. Permite observar: o Patrones de datos o Usos potenciales de los datos

5.- Aplicacin de un modelado de datos


Un modelado de datos es aplicado en los siguientes tipos de bases de datos:

Bases de datos jerrquicas


stas son bases de datos que, como su nombre indica, almacenan su informacin en una estructura jerrquica. En este modelo los datos se organizan en una forma similar a un rbol (visto al revs), en donde un nodo padre de informacin puede tener varios hijos. El nodo que no tiene padres es llamado raz, y a los nodos que no tienen hijos se los conoce como hojas.

Base de datos de red


ste es un modelo ligeramente distinto del jerrquico; su diferencia fundamental es la modificacin del concepto de nodo: se permite que un mismo nodo tenga varios padres (posibilidad no permitida en el modelo jerrquico).

Modelado de Datos
Base de datos relacional.

Investigacin Punto Net

ste es el modelo ms utilizado en la actualidad para modelar problemas reales y administrar datos dinmicamente.

6.- Modelos de un Modelado de datos


Varias tcnicas son usadas para modelar la estructura de datos. La mayor parte de sistemas de base de datos son construidos en torno a un modelo de datos particular, aunque sea cada vez ms comn para productos ofrecer el apoyo a ms de un modelo. Ya que cualquier varia puesta en prctica lgica modela fsica puede ser posible, y la mayor parte de productos ofrecern al usuario algn nivel de control en la sintona de la puesta en prctica fsica, desde las opciones que son hechas tienen un efecto significativo sobre el funcionamiento. Un ejemplo de esto es el modelo emparentado: todas las puestas en prctica serias del modelo emparentado permiten la creacin de ndices que proporcionan rpido acceso a filas en una tabla si conocen los valores de ciertas columnas.

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

Investigacin Punto Net

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

Investigacin Punto Net

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.

7.- Clasificacin de un Modelado de datos


Una opcin bastante usada a la hora de clasificar los modelos de datos es hacerlo de acuerdo al nivel de abstraccin que presentan:

Modelado de Datos
Modelos de Datos Conceptuales

Investigacin Punto Net

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

Modelos de Datos Lgicos


Son orientados a las operaciones ms que a la descripcin de una realidad. Usualmente estn implementados en algn Manejador de Base de Datos. El ejemplo ms tpico es el Modelo Relacional, que cuenta con la particularidad de contar tambin con buenas caractersticas conceptuales (Normalizacin de bases de datos). En los modelos lgicos, las descripciones de los datos tienen una correspondencia sencilla con la estructura fsica de la base de datos. Modelos lgicos basados en objetos.- se utilizan para describir los datos en los niveles conceptual y de visin. Se caracterizan por el hecho de que permiten una estructuracin bastante flexible y hacen posible especificar claramente las limitantes de los datos. Algunos de los ms conocidos son: El modelo entidad - relacin El modelo binario El modelo semntico de datos El modelo infolgico

Modelado de Datos

Investigacin Punto Net

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.

Atributos: Nombre, Edad, Semestre, Id.

Entidades: Alumno, Saln, Profesor.

Entidades Dbiles: No tienen llaves primarias.

objetos.

Generalizacin: Agrupa propiedades en comn a diferentes

Relacin Cardinalidad

Ejemplo:

Cardinalidad.-

(Muchos a Muchos)

(Uno a Muchos)

Modelado de Datos

Investigacin Punto Net

(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

8.- Restricciones de integridad de un modelado de datos


En el mundo real existen ciertas reglas que deben cumplir los elementos existentes. En la base de datos deseamos que reflejen lo mas fielmente posible el universo que se representa (si hacemos una BD de un hospital deber representar elementos del hospital), por lo tanto debemos recoger en nuestro sistema de informacin el universo lo mas fielmente posible para que al desarrollar el esquema de la BD junto con los objetos, evocaciones y propiedades que los mismos se cumplan estas reglas llamadas restricciones semnticas o de integridad las cueles pueden ser definidas como condiciones que limitan al conjunto de ocurrencias validas de un esquema, la semntica de los datos que un principio la controlaba manualmente el usuario. Hoy en da las restricciones de integridad suelen estar dispersas por la BD en vez de estar dispersas por las diferentes aplicaciones.

9.- Ejemplo de un modelado de datos


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 oposicin 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 catlogo 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 ms nos conviene, el horario al que vamos a asistir, y con esta informacin nos matriculamos. Como forma de pago, en este caso, vamos a utilizar un pago mensual, y queremos que se nos domicilie el pago a travs de nuestra cuenta bancaria. En la academia, llegado este punto, introducen en su sistema de informacin nuestros datos y nos imprimen el contrato de prestacin 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 pequea cantidad del primer recibo. En el siguiente da 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.

Modelado de Datos
El modelo de datos

Investigacin Punto Net

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

Investigacin Punto Net

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

Investigacin Punto Net

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.)

Investigacin Punto Net

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

Investigacin Punto Net

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

You might also like