Ingeniería de software I

Trabajo presentado por: Jorge Armando Toledo Barandica

BAJO RENDIMIENTO EN TRANSFERENCIA
DE DATOS COMO RESULTADO DEL USO
Cesar Augusto Tamayo Hernández
Manuel Octavio Rodríguez Diaz
Luis Ariel Gonzales Quezada
Francisco Javier Jiménez Cohen
Nelson Alfredo Casas Sanabria
Javier Andrés Gonzales

DE
Tutora: ORMS LICENCIADOS EN SISTEMAS
Luisa María Jiménez Ramos

Ciudad: Bogotá (Colombia)

CON GRAN FLUJO DE DATOS.

Fecha: 10 de Marzo de 2020

TABLA DE CONTENIDO

1. Introducción........................................................................................................................................3

2. Justificación.........................................................................................................................................6
 1

3. DESCRIPCIÓN del Problema.................................................................................................................7

4. Objetivos Generales............................................................................................................................8

4.1. Objetivos Específicos...................................................................................................................8

5. Marco de referencia............................................................................................................................9

5.1. Antecedentes investigativos........................................................................................................9

5.2. Estado del arte...........................................................................................................................10

5.3. Marco conceptual......................................................................................................................11

5.4. Diseño metodológico.................................................................................................................13

6. diseño metodologico.........................................................................................................................15

6.1. Metodología RUP.......................................................................................................................15

6.1.1. Fases del ciclo de vida........................................................................................................17

7. Referencias........................................................................................................................................18

8. Anexos...............................................................................................................................................19

8.1. Glosario de términos.................................................................................................................19

 2

Índice de Figuras

Figura 1 Código ejemplo de conexión a una base de datos.........................................................................4

Figura 2 Representación Modelo Vs Tabla BDD...........................................................................................5
Figura 3 Mapeo Objeto-Relacional ORM.....................................................................................................5
Figura 4 Capas de acceso a .net................................................................................................................13
Figura 5 - Capas de acceso a datos Java.....................................................................................................13
Figura 6 Estructura Front Back..................................................................................................................14
Figura 7 - Rational - The Software Development Company 2001..............................................................16
Figura 8 - Fases del ciclo de vida................................................................................................................17
 3

1.INTRODUCCIÓN

Siempre que se piensa en el desarrollo de un sistema de información, la persistencia toma gran

relevancia ya que el funcionamiento básico depende de que se mantengan la comunicación de la
aplicación con el motor de base de datos en todo momento; por más de 30 años distintas compañías
nos han brindado una solución para que los desarrolladores puedan guardar de manera estandarizada
sus datos , estas compañías como ORACLE, Microsoft , Sun Microsystem 1(Parte de Oracle desde el 2008)
quienes adoptaron el estándar Structured Query Language (SQL) nos brindan Los Sistemas de Gestión de
Bases de datos (SGBD), gracias a estos sistemas la organización y consulta de datos están a la mano de
todos lo que estudiamos un estándar por lo que se sigue una escalabilidad a la hora de programar con
ellas, recientemente nuevas formas de persistir los datos se han vuelto cada vez más recurrentes en el
cambiante mundo de la informática como los son los sistemas de gestión que no usan bases de datos
relacionales como lo son MongoDb, Cassandra ,Posgrest entre otras, dándole de donde escoger a los
desarrolladores distintas opciones para realizar las persistencia de los datos de su sistema de
información.

Si bien estos sistemas nos permiten guardar datos es preciso generar una conexión del sistema de
información con ellos; en el caso de las bases de datos relacionales cada proveedor de SGBD se ha
basado en el estándar creado por el SQL Access Group en 1992.[ CITATION uni20 \l 3082 ]

<< El objetivo de ODBC (Open DataBase Connectivity) es hacer posible el acceder a cualquier dato desde
cualquier aplicación, sin importar qué sistema de gestión de bases de datos (DBMS) almacene los datos.
ODBC logra esto al insertar una capa intermedia (CLI) denominada nivel de Interfaz de Cliente SQL, entre
la aplicación y el DBMS. El propósito de esta capa es traducir las consultas de datos de la aplicación en
comandos que el DBMS entienda.

Para que esto funcione tanto la aplicación como el S.G.B.D deben ser compatibles con ODBC, esto es que
la aplicación debe ser capaz de producir comandos ODBC y el DBMS debe ser capaz de responder a ellos.
Desde la versión 2.0 el estándar soporta SAG y SQL.

1
Sun Microsystems es una empresa informática adquirida por Oracle Corporation.
 4

El software funciona de dos modos, con un software manejador en el cliente, o una filosofía cliente-
servidor. En el primer modo, el driver interpreta las conexiones y llamadas SQL y las traduce desde el API
ODBC hacia el DBMS.>> [ CITATION MID20 \l 3082 ]

Para esto pueden entregar un componente preciso para cada lenguaje de programación.

La pregunta que surge es como tratar los objetos o datos existentes en las bases de datos, la respuesta
está dado por los conectores dados por los proveedores un ejemplo es la conexión de una base de datos
relacional (MYSQL) y C# (.NET Framework).

FIGURA 1 CÓDIGO EJEMPLO DE CONEXIÓN A UNA BASE DE DATOS.

Fuete: Elaboración propia a partir de la URL: https://dev.mysql.com/doc/dev/connector-
net/8.0/html/Properties_T_MySql_Data_MySqlClient_MySqlDataAdapter.htm

Los datos se manejan en base a MODELOS que son objetos del lenguaje de programación el cual son una
representación de los datos del lado del SGBD, por lo que la generación de un bloque de consulta en el
lenguaje de programación deberá incluir estos modelos esbozados en objetos.
 5

FIGURA 2 REPRESENTACIÓN MODELO VS TABLA BDD

Fuente: Elaboración propia

Gracias a tecnologias como lo son los Object Relational mapping (ORM) podemos tener estos Modelos
mapeados con la informacion casi de manera automatica, esto evitandole al desarrollador cientos de
lineas de codigo .

FIGURA 3 MAPEO OBJETO-RELACIONAL ORM

Fuente: https://programarfacil.com/blog/que-es-un-orm/

El problema de estas tecnologias son los proyectos grandes , ya que la confluencia de datos disminuye la
eficiencia y performarce de la aplicaciones por lo que conviene mas usar una conexión directa, en este
 6

proyecto se provera una manera en la cual el desarollador pueda mapear de manera genuina para
cualquier lenguaje de programacion , cualquier objeto de una base SQL o NoSql [ CITATION Har15 \l
3082 ], con el fin de bajar costos tanto humanos a la hora de escribir mas lineas de codigo como
economicos ya que se usan tecnologias de acesso mas directo a las SGBD.

2.JUSTIFICACIÓN

La disminución en el rendimiento en la velocidad de acceso a datos con el uso de ORM’s licenciados se

estima entre 20% y 25% en comparación con el mapeo directo sin usar conectores (Drivers) licenciados
de acuerdo a las pruebas realizadas en el banco Santander utilizando el esquema de cobro de por uso de
infraestructura que tiene contratado esta entidad bancaria, la demora en el acceso a datos implica Los
ORM destacan por su utilidad cuando de desarrollar aplicaciones sencillas que solo requieren de realizar
operaciones básicas: crear, leer, actualizar y eliminar. Y comienzan a mostrar sus flaquezas cuando de
realizar operaciones más complejas se trata. Y es que los ORM tienden a ser muy genéricos pues ese es
su propósito, tratar de realizar consultas más complejas u operaciones que requieran de operaciones
específicas de la base de datos es llevarlos al límite.

También es necesario decir que el uso de un ORM impacta sobre el desempeño, a diferencia de usar
otros métodos de acceso en los que el desarrollador puede priorizar el desempeño de acuerdo a lo que
está desarrollando.
 7

3.DESCRIPCIÓN DEL PROBLEMA

Devido a la implementacion de los cobros por uso y tiempo de transmicion de los datos , las empresas
deben optar por formas en que su capa de datos no demore mas de lo necesario las transacciones,
consultas o peticiones a sistema de persistencias en un servidor.

Actualmente en ciertos sectores del Banco Santader , tenemos sistemas que tienen ORM que no son
Open Source, pero al migrarlas a tecnologias ORM como lo es EntityFramework encontramos una
disminucion del 10% porciento del performace de la anterior, cuando se usan tecnologias mas directas
como ADO y ODBC la diferencia era muy significamente superior, por lo que se decide trabajar de ahora
en adelante con estas tecnologias.

¿Entoces toca mapear nuevamente todos los modelos a mano?, considerando que existen tablas que
tienen mas de 70 campos y storeProcedures que tienen 40 y mas es una labor titanica y muy suceptible
a errores.
 8

4.OBJETIVOS GENERALES

 Disminuir las Horas Hombre trabajadas para el mapeo de datos.

 Disminuir los Costos de Mantenimientos del sistema de Información.

 Aumentar la eficiencia de conexión e intercambio de datos.

 Generar una herramienta universal para Mapear los datos que no dependa del lenguaje de
Programación.

4.1. OBJETIVOS ESPECÍFICOS

 Diseño de un aplicativo para mapear los datos de una SGBD en un modelo asociado al lenguaje
de programación escogido.

 Entregar los datos de manera que el desarrollador solo los use Emulado el trabajo realizado por
una ORM sin caer en el problema de tener una capa más.

 Diseñar el plan de permisos para la utilización de esta aplicación.

 9

5.MARCO DE REFERENCIA

5.1. ANTECEDENTES INVESTIGATIVOS

Voy a usar la terminología de Java en las siguientes explicaciones, pero estos patrones se pueden usar
en cualquier lenguaje orientado a objetos.

DAO: Un objeto de acceso a datos es un patrón que a menudo se sigue cuando una aplicación necesita
interactuar con algún almacén de datos persistente (a menudo una base de datos). El DAO proporciona
una serie de operaciones al resto de la aplicación sin que la aplicación necesite conocer los detalles del
almacén de datos. Por ejemplo, puede haber operaciones para recuperar un subconjunto de datos,
actualizar los datos o eliminar los datos. Es mucho más genérico que ORM: simplemente es un objeto
que una aplicación utiliza para recuperar datos.

ORM: un ORM generalmente describe una biblioteca / API utilizada para hacer que las interacciones con
una base de datos sean más sólidas. Java tiene un ORM llamado JPA, que le permite persistir objetos
Java directamente en una base de datos sin tener que generar sus propias declaraciones SQL. Genera
objetos Java (a menudo llamados entidades) que coinciden con las columnas / tablas de una base de
datos, puebla el objeto Java y luego se llama persistir (objeto). Sabe cómo almacenarse en la base de
datos. Cuando consulta la base de datos para obtener datos, la devolverá en forma de objetos Java, en
lugar del desagradable ResultSet que obtiene cuando usa JDBC con SQL.

En resumen, un DAO es un objeto que abstrae la implementación de un almacén de datos persistente

lejos de la aplicación y permite una interacción simple con él. Un ORM es una biblioteca / API robusta
que proporciona un montón de herramientas para guardar / recuperar un objeto directamente a /
desde la base de datos sin tener que escribir sus propias declaraciones SQL.
 10

5.2. ESTADO DEL ARTE

En el desarrollo existen una infinidad de herramientas que nos ayudan a realizar nuestro trabajo de
forma más efectiva, sin embargo al mapear nuestras bases de datos no existen muchas herramientas un
ejemplo que encontramos similar al objetivo de nuestra herramienta es Json2charp2, Cuando se
consume un servicio externo que produce JSON (acrónimo de JavaScript Object Notation, «notación de
objeto de JavaScript»), es bueno tener tipos estáticos definidos localmente con los que se puede
codificar. Ganas seguridad tipográfica e inteligencia. Json2csharp realiza o escribe las clases que
coincidan con los datos proporcionados por dicho servicio.

La llegada de los lenguajes dinámicos ha hecho que consumir JSON sea mucho más fácil, aunque en C #
no disfrutará del beneficio adicional de la verificación en tiempo de compilación. Además, la escritura
dinámica solo está disponible si puede usar .NET 3 4.0+ Framework en sus proyectos.

Y en qué forma realiza el proceso de transformación Json2Charp al igual que varias aplicaciones esta
dirigía de manera online se escribe o pegue una cadena JSON o una URL que produzca JSON en el área
de texto grande de arriba, luego genera el esquema. Para traducir esta estructura de datos a un lenguaje
estático como C #, el esquema debe aplanarse en tipos que puedan manejar el caso más genérico.
Debido a esto, obtendrá los mejores resultados de json2csharp cuando su esquema JSON sea coherente
y pueda obtener resultados inesperados, pobres o simplemente rotos cuando ese no sea el caso.

Se utilizan reglas para los identificadores en C # no acomodarán las secuencias de caracteres permitidas
en JSON. Por ejemplo, {"0": "foobar"} es JSON completamente válido, pero no se compilará una
propiedad C # con el identificador "0". Además, los objetos o propiedades en su JSON pueden tener
nombres que entren en conflicto con los tipos de framework .NET que también pueden conducir a
errores del compilador.

2
Json2charp: Generar clases de c # a partir de Json
3
.NET: Es un framework de Microsoft que hace un énfasis en la transparencia de redes.
 11

5.3. MARCO CONCEPTUAL

Es importante tener conceptos claros sobre lo que realiza una transacción en un sistema de gestión de
base de datos (SGBD) es un conjunto de órdenes que se ejecutan como una unidad de trabajo es decir
forma indivisible o atómica. En la actualidad, existen multitud de SGBD y pueden ser clasificados según
la forma en que administran los datos en; Relacionales (SQL), No relacionales (NoSQL). Todo sistema
gestor de base de datos debe permitir cinco características principales: Persistencia, Concurrencia,
Recuperación ante fallos, gestión del almacenamiento secundario y facilidad de consultas.

Debemos familiarizarnos con dichos conceptos, actualmente trabajamos sobre programación orientada
objetos (POO), donde nace el concepto de SGBD-00 4 los objetos se almacenan directamente en la base
de datos, cumpliendo las características como Encapsulación, Identidad, Herencia y Polimorfismo, Junto
con Control de tipos y Persistencia. [ CITATION Mon04 \l 3082 ]

En resumen, los SGBD-00 nacen de la necesidad de proporcionar persistencia a los desarrollos hechos
con lenguajes de programación OO. Existen varias alternativas para proporcionar la persistencia, sin
embargo, la alternadita natural es utilizar un sistema gestor que permita conserva y explorar todas las
posibilidades de la programación orientada a objetos.

En los SGBD-OO es ODMG5 (Object Data Management Group) la organización encargada de estandarizar
todo lo relacionado con los SGBD-OO. El modelo de objetos ODMG permite que los diseños OO y las
implementación usando lenguajes OO puros como (Eifflel, Smalltalk, etc) y en mayor o menor medida
(java, C, C#, etc).

ODL (lenguaje de definición de objetos) es un lenguaje para definir la especificación de los tipos de
objetos en sistemas compatibles con ODMG. En otras palabras, el ODL es el equivalente al DDL
(lenguaje de definición de datos).

Una característica importante de un ODL es ofrecer al diseñador de base de datos un sistema de tipos
semejantes a los de otros lenguajes de programación OO. Los tipos permitidos son:

Tipos básicos: incluyen los tipos atómicos (Boolean, Float, Short, Long, Double, Chart, etc) y las
enumeraciones.

4
SGBDOO: Sistema que combina características de orientación a objetos y lenguajes de programación OO con
capacidades de bases de datos.
5
http://www.odbms.org/odmg-standard/
 12

Tipos de interfaz o estructurados: son tipos complejos obtenidos al combinar tipos básicos:

 Conjunto (Set<tipo>) son valores finitos del elemento del tipo.

 Bolsa (Bag<tipo>) Una bolsa permite a un elemento aparecer más de una vez, a diferencia de los
conjuntos, por ejemplo {1,2,1} es una bolsa, pero no un conjunto.
 Lista (List<tipo>) denota valores de listas ordenadas finitas conteniendo 0 o más elementos del
tipo.
 Array (Array<tipo.i> denota el tipo cuyos elementos son arrays de i elementos del tipo.

Por lo tanto, con la ayuda de ODL se puede crear el esquema de cualquier base de datos en un SGBD-OO
que siga el estándar ODMG.

Formalmente ODMG sugiere definir un OML (Lenguaje de Manipulación de Objetos) que sea la
extensión de un lenguaje de programación de forma que se puedan realizar las operaciones típicas de
creación, eliminación, modificación e identificación de objetos desde el propio lenguaje como se haría
con objetos que no fueran persistentes.

Un tipo de objeto representa una entidad del mundo real y se compone de los siguientes elementos:

 Su nombre, que sirve para identificar el tipo de los objetos.

 Sus atributos, que modelan la estructura y los valores de los datos de este tipo.
 Sus métodos, que especifican el comportamiento. Son procedimientos y funciones escritos en
un lenguaje de programación.

Continuemos emergiéndonos en la integración a las bases de datos utilizando ADO.NET, Para permitir la
integración de datos en aplicaciones distribuidas y escalables, Visual Studio .NET es compatible con una
nueva generación de tecnología de acceso a dato ADO.NET es un conjunto de componentes del software
que pueden ser usados por los programadores para acceder a datos y a servicios de datos.

5.4. DISEÑO METODOLÓGICO

 13

Para poder tener datos que ayuden a fundamentar un solución adecuada en el tratamiento de
información, en este caso el obtener máximo performance posible, sin disminuir los tiempos de
desarrollo acostumbrados por la utilización de ORM o librerías externas, se tienen que evaluar las
diferentes capas de acceso de un sistema en cuestión, con ello se puede analizar cuantas capas de más
tiene el sistema y como son los tiempos de ejecución en cada caso.

FIGURA 4 CAPAS DE ACCESO A .NET

Fuente: https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/ef/overview

FIGURA 5 - CAPAS DE ACCESO A DATOS JAVA

Fuente:
https://docs.jboss.org/hibernate/orm/5.3/userguide/html_single/Hibernate_User_Guide.html 
 14

La Figura 4 Capas de acceso a .net A refleja la estructura de Acceso a datos de .NET Framework y a la
derecha estructura de Acceso a datos Java.

El análisis se debe focalizar los puntos de entrada y salida de las conexiones para poder generar de
manera automática los modelos para el acceso a datos de manera nativa de esta manera se quiere
disminuir los agentes externos y los tiempos de esperas de los sistemas de información.

FIGURA 6 ESTRUCTURA FRONT BACK

Fuente: Elaboración propia a partir documentación ncapas de Microsoft.
 15

6. DISEÑO METODOLOGICO

6.1. METODOLOGÍA RUP

La metodología que utilizaremos es RUP por sus siglas en inglés (Rational Unified Process) que
corresponde a un proceso de Ingeniería de Software que provee una aproximación para asignar tareas y
responsabilidades en una organización. Su principal objetivo es asegurar la producción de software de
alta calidad, el cual llega a las necesidades del cliente final, por medio de un cronograma presupuesto
predecibles.

El Proceso Unificado Racional es un proceso de producto, desarrollado y financiado por Rational

Software, grupo que se encarga de trabajar de la mano con clientes y socios en buscando el
aseguramiento de los procesos sea actualizado y mejorado constantemente para evolucionar y probar
mejores prácticas.

Con la implementación de RUP mejora la productividad grupal mediante la asignación a la línea base del
conocimiento a cada miembro, con guías, plantillas y mentores de herramientas para todas las
actividades críticas de desarrollo. De esta forma, no importa en qué área se esté trabajando; ya sea
requerimientos, diseño, pruebas, administración del proyecto o administración de configuración; todos
los miembros del grupo comparten un lenguaje, procesos y vista de cómo desarrollar el software en
común.

Cabe recalcar que este proceso crea y mantiene modelos, es decir, en vez de enfocarse en la producción
de grandes cantidades de documentación, enfatiza el desarrollo y mantención de modelos –
representaciones altamente semánticas de sistemas de software en desarrollo.

Esta metodología utiliza el Lenguaje Unificado de Modelación (Unified Modeling Language – UML). UML
es un lenguaje estándar que permite expresar claramente requerimientos, arquitectura y diseños. Fue
originalmente creado por Rational Software y ahora es mantenido por la organización de estándares
Object Management Group (OMG).

El Proceso Unificado Racional está soportado por herramientas que generalmente automatizan gran
parte del proceso. Son usadas para crear y mantener los varios objetos – modelos en particular – del
proceso de ingeniería de software: modelado visual, programación, pruebas, entre otros. Son
 16

invaluables para el soporte contable con la administración de cambios, así como con la administración
de configuración en cada iteración.

Se puede decir que este proceso es configurable, es decir, “encaja” o va bien tanto con grupos pequeños
de desarrollo (incluso 1 persona) cómo grupos grades (organizaciones y empresas). [ CITATION Wen16 \l
3082 ]

Las características que posee es que permite a los procesos se adapten a las necesidades y
requerimientos de la organización las cuales son:

 Forma disciplina de asignar tareas y responsabilidades

 Implementar las mejores prácticas en Ingeniera de Software
 Desarrollo interactivo
 Administrado mediante casos de uso
 Se centra en la arquitectura y se base en componentes
 Modelado visual del software
 Es interactivo e incremental
 Artefactos y roles que se pueden desempeñar a lo largo del proceso

FIGURA 7 - RATIONAL - THE SOFTWARE DEVELOPMENT COMPANY 2001.

 17

Fuente:
https://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices
_TP026B.pdf

6.1.1. FASES DEL CICLO DE VIDA

En el ciclo de vida RUP se basa en cuatro (4) fases Inicio, Elaboración, construcción y Transición.

Inicio
Descripcion del
Elaboración
producto final, idea
clara, se identifican Se detallas los casos de
construcción
riesgos acompañados uso y se diseña la
del levantamiento de arquitectura del Enfocada en la
Transición
Información. sistema eliminando los eficiencia y
riesgos. Apoyo en el operatividad del Verificacion del sistema
estandar IEEE83. producto a entregar, este listoa para la
tomando en cuenta los entrega al usuario final,
requerimientos del los errores deben estar
usuario. definir corregidos y comprobar
lenguaje de que se cumpla con las
programacion y base de especificaciones. en
datos. esta fase se incluye al
participacion del
usuario final.

FIGURA 8 - FASES DEL CICLO DE VIDA

Fuente: Elaboración propia a partir del ciclo de vida de RUP.

Ventajas y desventajas

Ventajas

 Está basada en las mejores prácticas de metodológicas

 Facilita la reutilización del código fuente.
 Procesos visibles en etapas tempranas.
 Se utiliza para proyectos pequeños, medianos y grandes
 Los usuarios están involucrados en cada fase.

Desventajas

 Este modelo genera trabajo extra no recomendable para proyectos pequeños

 Las interacciones de cada ciclo pueden tomar más tiempo del establecido
 18

 Requiere conocimientos en UML y cada uno de sus procesos.

7.REFERENCIAS

ecured. (18 de 02 de 2020). Enciclopedia colaborativa en la red cubana. Obtenido de

https://www.ecured.cu/NoSQL

Harol Andrey Herrera, C. R. (07 de 11 de 2015). La nueva tendencia en el manejo de datos. Obtenido de
https://revistas.udistrital.edu.co/index.php/tia/article/view/8649/pdf

Montero, S. F. (2004). Acceso a datos. Madrid: RA-MA.

Oracle. (19 de 02 de 2020). Oracle. Obtenido de https://developer.oracle.com/databases/

unipython.com. (19 de 02 de 2020). unipython. Obtenido de https://unipython.com/acceso-a-bases-de-

datos-con-pyodbc/

Viveros, M. N. (17 de 02 de 2020). Cidecame. Obtenido de

http://cidecame.uaeh.edu.mx/lcc/mapa/PROYECTO/libro21/43_conectores_de_una_base_de_d
atos.html

W, W. J. (01 de 01 de 2016). Obtenido de PONTIFICIA UNIVERSIDAD CATÓLICA:

http://repositorio.puce.edu.ec/bitstream/handle/22000/11264/Documento%20Disertaci
%C3%B3n%20Wendy%20Jaramillo.pdf?sequence=1
 19

8.ANEXOS

8.1. GLOSARIO DE TÉRMINOS

API: Interfaz de programación de aplicaciones.

Registro: Colección de datos relacionados. Es una ocurrencia o instancia de una entidad conformada por
un conjunto particular de valores de cada atributo.

Dato: Palabras o números que por sí solos no tienen significado.

Tipo de datos: Numérico, alfabético, carácter, lógico y fecha.

Campo: Es el área de almacenamiento para almacenar datos de un tipo específico.

Base de Datos: es una serie de datos organizados y relacionados entre sí, los cuales son recolectados por
los sistemas de información de una empresa o negocio.

Entidad: objeto del mundo real que podemos distinguir del resto de objetos y del que nos interesan
algunas propiedades. Puede ser un objeto físico (persona, lugar) o una abstracción (evento) se
representa con un rectángulo.

Atributos: representan las propiedades definitorias o cualidades del tipo de entidad. Se representa con
un ovalo.

Oracle: Compañía especializada en el desarrollo de soluciones de nube y locales [ CITATION Ora20 \l

3082 ]

Sistema de Gestión de Base de Datos: Los SGBD son un tipo de software muy específico, dedicado a
servir de interfaz entre la base de datos, usuario y las aplicaciones que utilizan. Se compone de un
lenguaje de definición de datos, de un lenguaje de manipulación de datos y de un lenguaje de consulta.

SQL: Es un lenguaje estructurado de consulta para base de datos relacionales; permite crear, definir y
manipular la base de datos.

ORM: Mapeo objeto-relacional (más conocido por su nombre en inglés, Object-Relational mapping, o
sus siglas O/RM, ORM, y O/R mapping)

ODBC: Open DataBase Connectivity (ODBC) es un estándar de acceso a las bases de datos desarrollado
por SQL Access Group (SAG) en 1992.

RDBMS: Relational Database Management System.

NOSLQ: A veces ampliado a "no sólo SQL" [ CITATION ecu20 \l 3082 ]

20