• Author / Uploaded
• martinlguzmanc

Citation preview

Universidad del Valle de Guatemala Facultad de Ingeniería Departamento de Ingeniería en Ciencias de la Computación CC3012 – Modelado de Base de Datos Catedrática: Lynette García

Tarea No.5

Django ORM

Trabajo presentado por: Luis Carlos Aldana Molina, 08261 Martín Luis H. Guzmán Colmenares, 08041 Byron Orlando Morales Sequén, 08414 Guatemala, 03 de septiembre de 2011

Django ORM is licensed under Creative commons Attribution- Noncommercial-Share Alike 3.0 Guatemala License

1/22

RESUMEN Django es un entorno de desarrollo web escrito en Python que fomenta el desarrollo rápido y el diseño limpio y pragmático. Django es un framework web de código abierto escrito en Python que permite construir aplicaciones web más rápido y con menos código. Este Framework está compuesto de un mapeo objeto-relacional para convertir los modelos de datos, un apoyo en configuración de URL, un sistema completo de plantillas, sistemas para realizar procesos de solicitud y administración de base de datos relacionales, lo que permite un óptimo desarrollo de aplicaciones. A partir de los modelos creados en Python, Django proporciona una abstracción de la base de datos a través de su API que permite crear, recuperar, actualizar y borrar objetos. También es posible que el usuario ejecute sus propias consultas SQL directamente. En el modelo de datos de Django, una clase representa una tabla en la base de datos y las instancias de esta serán las filas en la tabla.

ÍNDICE DE CONTENIDOS Página 1. Resumen

...............................................................................................

2

2. Introducción ...............................................................................................

4

3. Django como ORM

..................................................................................

4

..................................................................................

4

b. Desventajas ..................................................................................

4

a. Ventajas 4. Archivo model.py 5. Modelos

..................................................................................

5

...............................................................................................

5

a. Campos

..................................................................................

5

b. Métodos

..................................................................................

6

c. Herencia

..................................................................................

7

6. Manejadores ...............................................................................................

8

7. Manipulación de datos

.....................................................................

9

a. Crear objetos ..................................................................................

9

b. Guardar cambios en objetos ........................................................

9 2/22

c. Recuperación de objetos

........................................................

10

.....................................................................

12

e. Actualizar múltiples objetos ........................................................

13

f.

..................................................................................

14

..................................................................................

14

d. Eliminar objetos SQL puro

8. Transacciones

a. Administración de transacciones b. Autocommit()

...........................................

14

......................................................................

15

c. Commit_on_success()

.........................................................

16

d. Commit_manually() ......................................................................

16

e. Savepoints

17

..................................................................................

9. Múltiples bases de datos

......................................................................

a. Definición de las bases de datos

............................................

b. Sincronización de las bases de datos

...............................

c. Enrutamiento automático de base de datos

18 18 19

..................

19

d. Selección manual de base de datos ............................................

20

e. Mover objetos entre bases de datos

...............................

21

Limitaciones de múltiples bases de datos ...............................

21

f.

10. Conclusiones ...............................................................................................

22

11. Bibliografía

22

...............................................................................................

3/22

INTRODUCCIÓN Django es un framework para el desarrollo de aplicaciones web, escrito en Python, que sigue el patrón de diseño de modelo vista controlador. Django pone énfasis en la reutilización de código, la conectividad y extensibilidad de componentes y el desarrollo rápido. El núcleo de Django consiste en un mapeo objeto-relacional que media entre los modelos de datos, definidos como clases de Python, y la base de datos relacional; un sistema para procesar peticiones y un despachador de URL basado en expresiones regulares. El presente trabajo intenta describir las características principales y el uso del ORM incluido en el framework Django.

Django como ORM El ORM de Django nos brinda una API libre para el acceso dinámico a bases de datos. Permite definir modelos directamente dentro del código de una aplicación, utilizando el lenguaje Python, que se relacionan con las entidades (auto-generadas) de una base de datos relacional tradicional.

Ventajas El ORM de Django es muy potente, porque permite sacar provecho de las ventajas del lenguaje para el cual está diseñado. Por ejemplo, podemos incluir consultas SQL para optimizar ciertos aspectos de nuestras aplicaciones (o interacciones con la base de datos). Existe un gran número de tipos de columna soportados. Además de que permite diseñar/definir tipos personalizados, los cuales pueden ser utilizados dentro de diferentes proyectos que estén dentro de Django. La forma en que Django maneja la meta-información de nuestros modelos ayuda personalizar cada uno de ellos. Tanto en el diseño lógico dentro de Django como dentro del diseño físico (parámetros para interactuar con el DBMS relacional con el que se esté trabajando).

Desventajas Los nombres de los campos no pueden contener dos signos de subrayado seguidos, debido a que crean confusiones con algunas de las funciones de Django. 4/22

Además, los problemas de rendimiento y claridad de código que son producidos al trabajar con herencia de múltiples modelos hacen que trabajar con estos paradigmas sea poco práctico.

Archivo model.py Es un archivo dentro de un proyecto de Django. En él se definen los modelos en los que se contiene la lógica del negocio de la aplicación; en otras palabras, contiene el diseño de la base de datos mediante clases de Python utilizando a la clase Model (incluida en el módulo model de Django). La representación completa de los modelos de la lógica de negocio son llamados amodel. Utilizando objetos de los modelos que se encuentran dentro del amodel es como interactuamos con la base de datos (crear, obtener, actualizar, eliminar registros o tuplas dentro de las tablas de la base de datos).

Modelos Campos La parte más importante de la definición de los modelos es la utilización de la descripción de los campos o atributos que lo componen. Para ello en Django, se utilizan variables de clase que toman como valor un objeto que hereda (directa o indirectamente) de la clase Field. Dentro de los campos se define el tipo de la columna que define; el widget que debe ser utilizado para el ingreso mediante la interfaz web; y, algunas validaciones simples o mínimas. Además se puede dar formato a los nombres de salida que tendrán los campos. Estás definiciones se hacen mediante el paso de parámetros a los constructores de los objetos de la clase. Básicamente existen dos tipos de parámetros: los parámetros específicos y los parámetros generales. Los parámetros específicos se utilizan para definir datos que son estrictamente esenciales en la definición de una columna (como ocurre con las columnas de texto, que necesitan definir el máximo número de caracteres que utilizan). Mientras que los parámetros generales, son aquellos que especifican información que todas las columnas contienen, tanto dentro de la base de datos, como de validación y métodos de entrada desde la interfaz web; por ejemplo si la columna acepta null (parámetro null), si un campo pertenece a la clave primaria de la tabla (primary_key), etc.

5/22

Algunos otros de los parámetros generales importantes son: • • • • •

blank: permitir dejar en blanco en la ingreso (de tipo validación). choices: muestra una lista de los valores admitidos para este campo (de tipo entrada). default: le poner un valor por defecto a la columna (de tipo entrada). help_text: muestra un texto de ayuda para el ingreso del campo (de tipo entrada). unique: no permite valores repetidos dentro de la base de datos (actúa sobre la base de datos).

Además, el ORM de Django permite definir relaciones entre los modelos (de forma análoga a como lo hace un DBMS). Los tipos de relaciones que soporta son: •

Uno a uno: Se especifica mediante la función OneToOneField, que toma como parámetro la clase a la que debe hacer referencia.

•

Uno a muchos: Se especifica mediante la función ForeignKey, que toma como parámetro la clase a la que debe hacer referencia.

•

Muchos a muchos: Existen dos formas de definir relaciones muchos a muchos: ◦ Simple: cuando la relación se hace únicamente por atributo. Se especifica mediante la función ManyToManyField, que toma como parámetro la clase a la que debe hacer referencia. ◦ Compuesta: cuando la relación se por más de un atributo atributo. Se especifica mediante la función ManyToManyField, que toma como parámetro la clase a la que debe hacer referencia y además en el parámetro through se específica la clase por medio de la cual se hace la relación.

Métodos Los métodos dentro de las clases que heredan de la clase Model actúan únicamente sobre un objeto (instancia) a la vez, por ello se denominan métodos a nivel de tupla (row level) dentro de la base de datos. El permitirnos realizar estos métodos ayuda a mantener la lógica del negocio en un sólo lugar: el modelo. Existen métodos que son heredados de la clase Model, en algunas ocasiones puede resultar útil sobreescribirlos. Algunos de ellos son:

6/22

• • • •

__unicode__: debe brindar la representación de texto extendido de una tupla (objeto). get_absolute_url: nos da la URL directa para llegar a la información de este objeto dentro de la aplicación web. save: guarda la instancia actual dentro de la base de datos. delete: elimina el objeto actual de la base de datos.

Además, dentro de estos métodos podemos incluir sentencia SQL para manejar consultas, relaciones u otras acciones de forma más eficiente a como lo hace Django. También podemos extender las funcionalidades que nos brinda Django, creando operaciones que el framework no puede realizar por sí solo.

Herencia Utiliza las facilidades que brinda Python para utilizar herencia. Básicamente se permiten tres tipos de herencia: •

•

•

•

Herencia de clases base abstractas: Se crea un modelo abstracta (se específica en la meta-información), de ella se hereda hacia otros modelos los cuales automáticamente tienen todos las columnas de la clase base. Herencia de meta-información: la meta-información es heredada a los modelos que lo especifiquen pero tiene mayor prioridad la propia meta información del modelo (por ejemplo, el nombre de tabla se crea con el nombre especificado en la meta-información del modelo que hereda y no con la meta-información del modelo abstracto). Herencia multitabla: se realiza creando un modelo, y a partir de ese modelo se hereda hacia otro modelo. Esto se realiza creando una relación uno a uno dentro de la base de datos, lo que lleva a que la información completa este guardada en diferentes tablas dentro de la base de datos. Herencia apoderada de modelos (Proxy Model Inheritance): se realiza especificando la relación de proxy dentro de la meta-información del modelo que hereda. Esto hace que todas las acciones que se realicen sobre las instancias del modelo que hereda sean vistas en el modelo que ha sido heredado.

Hay que mencionar que en ningún tipo de herencia se soporta la sobreescritura de campos, dado que así es como se garantiza la integridad de los datos dentro de la misma base de datos.

7/22

Manejadores Una manejador es la interfaz que provee las operaciones a la base de datos para cada modelo, por lo que existe almenos un manejador por cada modelo. El manejador predeterminado que tiene cada modelo se encuentra en el campo objects, el cual puede ser sobre-escrito. Crear manejadores personalizados permite agregar funcionalidad a manejadores predeterminados, el cuál se ve reflejado dentro de la base de datos como funcionalidad a nivel de tabla. Además también permite modificar el conjunto de operaciones que permiten utilzar los manejadores preestablecidos, operaciones que involucren incluso la interacción con otros modelos. Esto se realiza al crear una clase que herede de la clase Manager que se encuentra en el modulo model, proporcionado por Django. Los manejadores son heredados cuando se realiza la herencia, incluso el manejador que se encuentra en objects. La única excepción a esto es cuando se hereda de una clase base abstracta, porque el manejador predeterminado se hereda pero no es el manejador principal del modelo que hereda. A continuación se muestra un ejemplo de implementación de un manejador. Figura No.0 – Ejemplo de manejadores

En este caso, tanto la clase MaleManager, como FemaleManager lo que hacen es retornar un QuerySet con los respectivos filtros para seleccionar a los hombres o mujeres.

8/22

Manipulación de datos Una vez se haya creado el modelo de los datos, Django provee automáticamente una API para la abstracción de la base de datos, para crear, recuperar, actualizar y eliminar los objetos.

Crear objetos Para representar una tabla en la base de datos utilizando objetos de Python, Django utiliza un sistema bastante intuitivo: Un modelo de clase representa una tabla de base de datos, y una instancia de esa clase representa un registro en particular en la tabla de la base de datos. Para crear un objeto, simplemente se instancia un objeto de una de estas clases con los argumentos requeridos por el modelo, y a continuación, llamar al método save() para guardarla en la base de datos. Para realizar este procedimiento Django lo que hace es convertir a una instrucción de INSERT de SQL lo que se está haciendo. Ésta se crea en el momento que se llama al método save(). En la figura de abajo se muestra un pequeño ejemplo de cómo crear objetos y meterlos a la base de datos. Figura No.1 – Ejemplo para crear objetos

Guardar cambios en objetos Para guardar un objeto que ya se encuentra en la base de datos es posible utilizar, nuevamente, el método save(). Cuando se hace uso de este método y el objeto ya se encuentra almacenado en la base de datos, los que hace Django es realizar una sentencia UPDATE de SQL. Por ejemplo, supongamos que b5 es un objeto que ha se encuentra en la base de datos. Por lo tanto para actualizar cambios es necesario llamar al método save() como se muestra en la siguiente figura. Figura No.2 – Ejemplo guardar cambios en objeto

9/22

Si lo que se desea es actualizar una llave foránea, se puede hacer de manera similar: Figura No.3 – Ejemplo guardar cambios en llave foránea

Por otro lado, si lo que se desea es agregar objetos en una relación de muchos a muchos, Django permite hacerlo de la siguiente forma: Figura No.4 – Ejemplo guardar cambios en relación muchos a muchos

Recuperación de objetos Para recuperar objetos de la base de datos es necesario construir un QuerySet a partir del Manager del modelo de la clase. Un QuerySet representa una colección de objetos de la base de datos. Otro concepto importante es el de filtro. Un filtro representa un criterio para reducir el número de resultados en función de los parámetros. En términos de SQL, un QuerySet representa una instrucción SELECT, mientras un filtro representa una cláusula WHERE o LIMIT. Cada modelo tiene un Manager. Por defecto, éste se llama: objects. Cabe destacar que para acceder al Manger, objects es necesario acceder directamente a través de la clase del modelo (no desde una instancia del objeto). Por ejemplo: Figura No.5 – Ejemplo acceder al Manager mediante la clase, no la instancia

10/22

Mediante el Manager obtenemos un QuerySet, que describe todos los objetos de una determinada clase en la base de datos. Con éstos es posible hacer varias cosas: •

Recuperar todos los objetos: La forma más sencilla es obteniendo todos los objetos de una clase por medio del Manager. Para hacer uso del mismo es posible utilizar el método all() sobre el Manager, para obtener todos los objetos en un QuerySet. Por ejemplo: Figura No.6 – Ejemplo recuperar todos los objetos de una clase

•

Recuperar objetos específicos con filtros : Usualmente es necesario únicamente recuperar un subconjunto de todos los objetos que se encuentran almacenados. Para recuperar un subconjunto es necesario refinar el conjunto QuerySet, mediante filtros. Las dos formas más comunes de hacerlo es mediante el uso de 2 métoso: ◦ filter(**kwargs): Devuelve un nuevo QuerySet que contiene los objetos que coinciden con los parámetros de búsqueda dados. ◦ exclude(**kwargs): Devuelve un nuevo QuerySet que contiene los objetos que no coinciden con los parámetros de búsqueda dados. Figura No.7 – Ejemplo recuperar objetos específicos con filtros

•

Recuperar objetos encadenando filtros: También es posible encadenar los filtros, para refinar las búsquedas. Figura No.8 – Ejemplo filtros encadenados

•

Recuperar un simple objeto con get: El método filter() siempre devolverá un QuerySet, sin importar que el resultado sea un único objeto. Si se desea obtener inmediatamente el objeto puede usarse el método get(). 11/22

Figura No.9 – Ejemplo recuperar con get

•

Limitar la cantidad de recuperaciones : Es posible limitar el número de resultados en una recuperación, utilizando la sintaxis de arreglos. Esto es equivalente a utilizar LIMIT de SQL y las cláusulas OFFSET. Por ejemplo, si se desea recuperar únicamente 5 elementos (LIMIT 5): Figura No.10 – Ejemplo limitar la cantidad de recuperaciones

Otro ejemplo podría ser si se desea recuperar 5 elementos, pero no los primeros 5 sino los segundos (LIMIT 5 OFFSET 5) Figura No.11 – Ejemplo limitar la cantidad de recuperaciones con OFFSET

•

Recuperar con operaciones booleanas: También es posible utilizar operaciones booleanas como AND y OR a la hora de realizar los filtros. Los parámetros que poseen los métodos filter() y get() representan una operación booleana AND. Si se desea realizar un OR es necesario especificarla mediante una barra vertical. La siguiente figura muestra un ejemplo:

Figura No.12 – Ejemplo uso de operaciones booleanas en una recuperación

Eliminar objetos Para eliminar objetos de la base de datos puede utilizarse el método delete(). Éste puede ser utilizado de varias formas. Por ejemplo: Figura No.13 – Ejemplo eliminar un objeto de la base de datos

12/22

Con este método es posible eliminar múltiples objetos, es decir, se pueden borrar todos los elementos que devuelva un QuerySet. Figura No.14 – Ejemplo eliminar objetos de un QuerySet

Sin embargo, hay que tener cuidado con el uso del método delete(), ya que cuando se manda a llamar, por defecto, emula el comportamiento de la restricción de SQL: ON DELETE CASCADE. En otras palabras, cuando se elimina un objeto, se eliminan también todos los objetos que tengan referencia hacia él. Por ejemplo: Figura No.15 – Ejemplo eliminar en cascada

Actualizar múltiples objetos Muchas veces lo que se desea es actualizar múltiples objetos, obtenidos mediante la recuperación de datos en un QuerySet. Para realizar esto se utiliza el método update(). Por ejemplo: Figura No.16 – Ejemplo actualizar múltiples objetos en QuerySet

El uso del método update() implica la conversión directa a una sentencia UPDATE de SQL. Por lo tanto no realiza una búsqueda y luego la guarda. Sin embargo, si se quiere modificar y actualizar cada elemento de un QuerySet por separado, puede recorrerse de la siguiente forma: Figura No.17 – Ejemplo uso de QuerySet como lista

13/22

SQL puro El uso de la capa de abstracción que provee Django puede ser bastante sencillo de utilizar. Sin embargo, si se desea, es posible utilizar sentencias SQL. Para esto se puede recurrir al método raw(). A continuación se muestran dos pequeños ejemplos de cómo utilizarlo: Figura No.18 – Ejemplo uso de SQL puro en un objeto

Figura No.19 – Ejemplo uso de SQL puro en una lista

Transacciones Django provee cómo controlar la forma en que se manejan las transacciones de la base de datos, si el manejador soporta transacciones. Por predeterminado, Django maneja una transacción abierta, la cual hace commit automáticamente cuando una función de actualización del modelo es invocada. Muy parecido a la configuración auto-commit para muchas bases de datos. Cuando se realiza una acción que necesita escribir en la base de datos, Django produce las sentencias INSERT/UPDATE/DELETE y luego hace el commit. No hay un rollback implícito.

Administración de transacciones Si se necesita más control sobre las transacciones, se pueden utilizar las funciones que provee Django para controlar las transacciones basadas en:

14/22

•

Funciones (decorador) Figura No.20 – Ejemplo función

•

Bloques de código (administrador de contexto) Figura No.21 – Ejemplo bloques de código

Autocommit() Configuración por defecto. Se puede utilizar para modificar el manejo de transacciones si se modificó la configuración global. Figura No.22 – Ejemplo auto-commit

15/22

Commit_on_success() Se utiliza como decorador para utilizar una sola transacción por función. Si la función retorna con éxito, Django hace commit al trabajo realizado dentro de la función. Si la función levanta una excepción, Django hace rollback al trabajo realizado. Figura No.23 – Ejemplo commit_on_success

Commit_manually() Se utiliza para tener control total sobre las transacciones. Si la vista realiza cambios en los datos y no se hace commit o rollback, Django levanta una excepción. Figura No.24 – Ejemplo commit_manually

16/22

Savepoints Los savepoints están disponibles en PostgreSQL y Oracle. Permiten hacer rollback parte de los cambios realizados en una transacción en lugar de hacer rollback a la transacción completa. Los savepoints no son útiles si se utiliza el comportamiento por defecto de Django. Sin embargo, si se utiliza otro comportamiento, cada transacción abierta acumula una serie de operaciones a la base de datos esperando a hacer commit o rollback. Los savepoints proveen la habilidad de realizar un rollback más específico. Los savepoints se manejan por tres funciones: 1. savepoint(): crea un nuevo savepoint. regresa el identificador de savepoint. 2. savepoint_commit(sid): actualiza el savepoint para incluir la operaciones que han sido realizadas desde la creación del savepoint. 3. savepoint_rollback(sid): hace un rollback hasta el punto donde se creó el savepoint.

Figura No.25 – Ejemplo de savepoint

17/22

Múltiples bases de datos Al utilizar Django es posible interactuar con varias bases de datos. Usualmente se maneja una única base de datos, pero si no es ese el caso hay que tomar algunas medidas adicionales.

Definición de las bases de datos El primer paso para utilizar más de una base de datos con Django es decirle a qué servidores de base de datos se van a utilizar. Esto se realiza mediante el establecimiento de las bases de datos. Éste permite el uso de aliases para referirse a las diferentes bases de datos, es decir a las diferentes conexiones. Las bases de datos pueden tener cualquier alias que se alija. Sin embargo, el alias predeterminado (default) tiene un significado especial. Django utiliza la base de datos con éste alias por defecto cuando no se ha seleccionado otra. Si no se tiene seleccionada una base de datos por defecto, es necesario tener cuidado de especificar en todo momento la base de datos que se desea actualizar. El siguiente es un ejemplo de la configuración que debe estar guardada en settings.py, en la que se definen 2 bases de datos, la default en PostgreSQL y una llamada users en MySQL.

Figura No.26 – Configuración de bases de datos de ejemplo

18/22

Sincronización de las bases de datos En Django, el comando syncdb sirve para sincronizar las bases de datos. Esta sincronización se realiza en una base de datos a la vez. Por defecto, sincroniza la base de datos default, pero utilizando el parámetro –database es posible sincronizar una base de datos diferente. Por lo tanto, para sincronizar los modelos de las bases de datos es necesario llamar al comando syncdb como se muestra en la siguiente figura. Figura No.27 – Sincronización de las bases de datos

Enrutamiento automático de base de datos La manera más fácil de utilizar varias bases de datos es mediante la creación de un esquema (scheme) de enrutamiento de base de datos. El esquema de enrutamiento por defecto se asegura de que los objetos sigan estando “atados” a su base de datos original. Es decir, un objeto recuperado de una base de datos, se guardará en la misma base de datos. El esquema de enrutamiento predeterminado garantiza que si no se especifica la base de datos, todas las consultas se realizan sobre la base de datos por defecto. Para activar el esquema de enrutamiento por defecto no es necesario configurar nada. Sin embargo si se desea que automáticamente se haga el uso desde diferentes bases de datos, es necesario definir la clase de enrutamiento, definiendo los siguientes 4 métodos: • • •

•

db_for_read(model, **hints) → Sugiere la base de datos que sedebe utilizar para las operaciones de lectura para los objetos del tipo model. db_for_write(model, **hints) → Suguiere la base de datos que debe ser utilizada para las operaciones de escritura para los objetos del tipo model. allow_relation(obj1, obj2, **hints) → True si la relación entre obj1 y obj2 debe ser permitida, False si la relación debe ser evitada. Se puede utilizar para hacer relaciones entre modelos de dos bases de datos. allow_syncdb(db, model) → Determina si el model debe poder sincronizarse con el alias de la base de datos db. Retorna un booleano con la respuesta.

Siempre que una base de datos intenta realizar una consulta a la base de datos debe saber a cuál hacerla. Ésto se hace utilizando el enrutamiento maestro.

19/22

Figura No.28 – Enrutamiento de maestro esclavo de ejemplo.

Selección manual de base de datos Django provee formas para tener un completo control del uso de las base de datos, dentro del código. Esta forma posee prioridad sobre el enrutamiento. Para hacer la selección manual de la base de datos a utilizar se puede utilizar el método using(). En las siguientes figuras se muestran algunos ejemplos. Figura No.29 – selección manual

Figura No.30 – guardar manualmente en base de datos 'legacy_users'

20/22

Mover objetos entre bases de datos Es permitido el tener relaciones entre las diferentes bases de datos. Cuando se crea un objeto, éste puede ser guardado en varias bases de datos tomando en cuenta algunas observaciones. Considérese la siguiente figura. Figura No.31 – Objetos entre bases de datos

Se empieza creando un objeto Person, con nombre 'Fred'. La siguiente instrucción corresponde a guardar a dicho objeto en la base de datos con alias 'first'. Al hacer esto al objeto se le crea una llave primaria (si no se especifica), para que sea adecuadamente insertado en la base de datos. Si no se ejecuta la línea “p.pk = None” existe el problema que al intentar guardar el objeto en la base de datos 'second' es necesario revisar que la llave primaria no se encuentre anteriormente usada. Para evitar ésto se puede, como se hace en el ejemplo, borrarle la llave primaria al objeto, o bien, forzar a que sea insertado de la siguiente forma: “p.save(using='second', force_insert=True).

Limitaciones de múltiples bases de datos Django no aporta ningún tipo de apoyo para las relaciones de muchos a muchos entre múltiples bases de datos. Ésto se debe a la integridad referencial. Con el fin de mantener una relación entre dos objetos, Django necesita saber que la clave primaria del objeto sea válida.

21/22

CONCLUSIONES •

•

•

• •

• •

La definición de campos o columnas es la parte más importante de los modelos, por ello es importante la personalización (mediante la utilización de parámetros, específicos o generales) que le demos a cada uno. La utilización de métodos dentro de los modelos, permiten crear funcionalidad a nivel de tupla. Lo que esto nos permite, es personalizar el comportamiento que tendrá cada uno de las instancias del modelo (y de su interacción con otras instancias de modelos). La utilización de Manejadores permite tratar la información a nivel de tabla, de tal forma que creando manejadores personalizados es posible crear o modificar operaciones que se realizan sobre el conjunto de datos que pertenecen al modelo al cual el manejador pertenece. Tanto la personalización de funciones a nivel de tuplas como funciones a nivel de tablas nos permiten mantener la lógica del negocio dentro de Django. Django provee automáticamente una API para la abstracción de la manipulación de los datos de la base de datos. Ésta provee muchas funciones para la creación, recuperación, actualización y eliminación de los datos de forma sencilla. Django provee forma de controlar y manejar transacciones de la base de datos, siempre y cuando el manejador soporte las transacciones. Django acepta interactuar con múltiples bases de datos de manera simultánea. Para acceder a ellas existen dos formas: el enrutamiento automático y la selección manual. Es posible que un objeto interactúe con más de una base de datos. Sin embargo, Django está limitado cuando se trata de relaciones de muchos a muchos entre diferentes bases de datos.

BIBLIOGRAFÍA • • • • • • •

Django. “Models”. Django documentation. Sitio web: https://docs.djangoproject.com/en/1.3/topics/db/models/ Django. “Model instance reference”. Django documentation. Sitio web: https://docs.djangoproject.com/en/dev/ref/models/instances/?from=olddocs Django. “Making queries”. Django documentation. Sitio web: https://docs.djangoproject.com/en/1.3/topics/db/queries/ Gomaa, A. “The Django ORM Problem”. 2007. Sitio web: http://adam.gomaa.us/blog/2007/aug/26/the-django-orm-problem/ The Django Book. Capítulos 5 y 10. Sitio web: http://www.djangobook.com/en/2.0/ CustomSolutions. “Desarrollo Django”. Sitio web: http://www.customsolutions.es/desarrollo-aplicaciones-django/ Djngo en español. “¡Descubre Django!”. Sitio web: http://django.es/ 22/22