![\"ERD](\"https:\/\/www.booksofall.com\/wp-content\/uploads\/2026\/06\/img_6a324e36bef6a.png\")
<\/p>\nImagina que est\u00e1s construyendo una casa. No comenzar\u00edas cogiendo un martillo y clavos; empezar\u00edas con conversaciones sobre qu\u00e9 tipo de hogar deseas, luego crear\u00edas bocetos, desarrollar\u00edas planos detallados y finalmente llegar\u00edas a la construcci\u00f3n real. El modelado de datos sigue el mismo principio exacto, pero muchos proyectos de software fracasan porque los equipos saltan directamente a la codificaci\u00f3n sin una planificaci\u00f3n adecuada.<\/p>\n
En el mundo actual impulsado por los datos, las bases de datos impulsan todo, desde tu aplicaci\u00f3n m\u00f3vil favorita hasta los sistemas financieros globales. Pero, \u00bfc\u00f3mo transformamos requisitos empresariales vagos como \u00abNecesitamos rastrear los pedidos de clientes\u00bb en una base de datos completamente funcional capaz de manejar millones de transacciones? La respuesta est\u00e1 en un enfoque sistem\u00e1tico de tres niveles para el modelado de datos.<\/p>\n
Este estudio de caso te gu\u00eda a trav\u00e9s del recorrido desde conceptos empresariales abstractos hasta la implementaci\u00f3n concreta de una base de datos. Ya sea que seas un analista de negocios tratando de comunicar requisitos, un desarrollador junior prepar\u00e1ndose para su primer proyecto de base de datos o un gerente de proyectos supervisando una iniciativa de datos, comprender estos niveles de modelado transformar\u00e1 la forma en que abordas proyectos impulsados por datos.<\/p>\n
Antes de adentrarnos en los detalles, entendamos la visi\u00f3n general. Los modelos conceptual, l\u00f3gico y f\u00edsico\u2014a menudo representados como Diagramas Entidad-Relaci\u00f3n (DER)\u2014representan tres formas distintas de ver los datos dentro de un dominio. Pi\u00e9nsalos como lentes diferentes a trav\u00e9s de los cuales observamos la misma informaci\u00f3n, cada uno con un prop\u00f3sito y audiencia \u00fanicos.<\/p>\n
<\/p>\n
El enfoque de modelado de tres niveles proporciona perspectivas diferentes para diferentes partes interesadas<\/em><\/p>\n \u00bfQui\u00e9n utiliza cada modelo?<\/strong><\/p>\n Analistas de negocios<\/strong>\u00a0trabajan t\u00edpicamente con modelos conceptual y l\u00f3gico para capturar los datos requeridos y generados por los sistemas desde una perspectiva empresarial<\/p>\n<\/li>\n Dise\u00f1adores de bases de datos<\/strong>\u00a0perfeccionan estos primeros dise\u00f1os para producir el modelo f\u00edsico, presentando la estructura f\u00edsica de la base de datos lista para la construcci\u00f3n real de la base de datos<\/p>\n<\/li>\n Desarrolladores y DBAs<\/strong>\u00a0implementan el modelo f\u00edsico para crear la base de datos real<\/p>\n<\/li>\n<\/ul>\n Punto clave:<\/strong>\u00a0La belleza de este enfoque es que permite a diferentes partes interesadas trabajar a su nivel adecuado de abstracci\u00f3n, manteniendo la consistencia en todas las fases. Los responsables empresariales no necesitan entender claves for\u00e1neas ni \u00edndices, y los administradores de bases de datos no necesitan preocuparse por el lenguaje empresarial.<\/p>\n Con herramientas como Visual Paradigm, los profesionales pueden dibujar los tres tipos de modelos y avanzar entre ellos de forma fluida utilizando la funci\u00f3n de transici\u00f3n de modelos, asegurando consistencia y trazabilidad durante todo el proceso de dise\u00f1o.<\/p>\n El DER conceptual modela la informaci\u00f3n recopilada directamente de los requisitos del negocio. Las entidades y relaciones se definen en torno a las necesidades del negocio, sin considerar los aspectos t\u00e9cnicos del dise\u00f1o de bases de datos. Este representa el modelo m\u00e1s simple entre los tres niveles y sirve como fundamento para todo lo que sigue.<\/p>\n Ejemplo de ERD conceptual<\/em><\/p>\n El modelo conceptual cumple varias funciones vitales:<\/p>\n Proporciona una visi\u00f3n de alto nivel<\/strong>\u00a0comprensible para los interesados no t\u00e9cnicos<\/p>\n<\/li>\n Facilita la comunicaci\u00f3n<\/strong>\u00a0entre los usuarios del negocio y los equipos de TI<\/p>\n<\/li>\n Establece la base<\/strong>\u00a0para las fases posteriores de modelado<\/p>\n<\/li>\n Identifica las entidades clave del negocio<\/strong>\u00a0y sus relaciones sin restricciones t\u00e9cnicas<\/p>\n<\/li>\n<\/ol>\n El ERD conceptual respalda \u00fanicamente el uso de generalizaci\u00f3n para modelar la relaci\u00f3n de tipo ‘una clase de’ entre dos entidades. Por ejemplo, un Tri\u00e1ngulo es una clase de Forma. Este uso refleja la generalizaci\u00f3n en UML. Es importante destacar quesolo el ERD conceptual soporta la generalizaci\u00f3n<\/strong>, lo que lo hace especialmente adecuado para capturar conceptos empresariales jer\u00e1rquicos.<\/p>\n Empieza con sustantivos y verbos<\/strong>: En los documentos de requisitos, las entidades suelen ser sustantivos (Cliente, Pedido, Producto) y las relaciones son verbos (coloca, contiene, env\u00eda)<\/p>\n<\/li>\n No te vuelvas t\u00e9cnico<\/strong>: Resiste la tentaci\u00f3n de pensar en claves primarias, claves for\u00e1neas o tipos de datos en esta etapa; enf\u00f3cate en lo que el negocio necesita rastrear<\/p>\n<\/li>\n Valida con los interesados<\/strong>: Antes de continuar, revisa el modelo conceptual con los usuarios del negocio para asegurarte de que nada falte<\/p>\n<\/li>\n Mant\u00e9nlo simple<\/strong>: Un buen modelo conceptual debe caber en una sola p\u00e1gina y ser comprensible para cualquier persona en la organizaci\u00f3n<\/p>\n<\/li>\n<\/ol>\n El ERD l\u00f3gico tambi\u00e9n modela la informaci\u00f3n recopilada a partir de los requisitos del negocio, pero introduce m\u00e1s complejidad que el modelo conceptual. Pi\u00e9nsalo como el puente entre las necesidades del negocio y la realidad t\u00e9cnica.<\/p>\n Ejemplo de ERD l\u00f3gico<\/em><\/p>\n En el modelo l\u00f3gico, se especifican los tipos de columna, lo que a\u00f1ade precisi\u00f3n a la estructura de datos. Sin embargo, establecer los tipos de columna en esta fase es\u00a0opcional<\/strong>\u00a0y deber\u00eda hacerse principalmente para ayudar al an\u00e1lisis del negocio, m\u00e1s que con fines de creaci\u00f3n de bases de datos.<\/p>\n El modelo l\u00f3gico cierra la brecha entre los conceptos empresariales abstractos y la implementaci\u00f3n t\u00e9cnica mediante:<\/p>\n Definir atributos<\/strong>\u00a0para cada entidad con tipos de datos adecuados<\/p>\n<\/li>\n Establecer relaciones detalladas<\/strong>\u00a0entre entidades<\/p>\n<\/li>\n Normalizar las estructuras de datos<\/strong>\u00a0para reducir la redundancia<\/p>\n<\/li>\n Mantener la independencia<\/strong>\u00a0de sistemas espec\u00edficos de gesti\u00f3n de bases de datos<\/p>\n<\/li>\n<\/ul>\n Conozca sus reglas de negocio<\/strong>: Aqu\u00ed es donde captura la cardinalidad (uno a uno, uno a muchos, muchos a muchos) y la opcionalidad (si una relaci\u00f3n es obligatoria)<\/p>\n<\/li>\n Normalice sin sobrenormalizar<\/strong>: Busque la Tercera Forma Normal (3FN), pero recuerde que a veces la desnormalizaci\u00f3n es aceptable para ciertos escenarios de negocio<\/p>\n<\/li>\n Use nombres de atributos significativos<\/strong>: Los nombres deben ser lo suficientemente descriptivos para que los usuarios de negocio los entiendan<\/p>\n<\/li>\n Piense en la integridad de los datos<\/strong>: Considere qu\u00e9 constituye datos v\u00e1lidos; por ejemplo, una fecha de pedido siempre debe estar en el pasado<\/p>\n<\/li>\n<\/ol>\n El diagrama ER f\u00edsico representa el plano de dise\u00f1o real de una base de datos relacional. Ilustra c\u00f3mo deben estructurarse y relacionarse los datos dentro de un Sistema Gestor de Bases de Datos (DBMS) espec\u00edfico. Aqu\u00ed la teor\u00eda se encuentra con la realidad.<\/p>\n Ejemplo de diagrama ER f\u00edsico<\/em><\/p>\n 1. Tipos de datos precisos<\/strong> 2. Convenciones de nomenclatura<\/strong> 3. Claves y restricciones<\/strong><\/p>\n Claves primarias<\/strong>: Identifican \u00fanicamente cada registro<\/p>\n<\/li>\n Claves for\u00e1neas<\/strong>: Mantienen la integridad referencial entre tablas<\/p>\n<\/li>\n Restricciones \u00fanicas<\/strong>: Evitan valores duplicados<\/p>\n<\/li>\n Restricciones de verificaci\u00f3n<\/strong>: Validan los datos seg\u00fan las reglas del negocio<\/p>\n<\/li>\n Valores predeterminados<\/strong>: Proporcionan valores predeterminados razonables cuando sea apropiado<\/p>\n<\/li>\n<\/ul>\n 4. Optimizaci\u00f3n del rendimiento<\/strong><\/p>\n Estrategias de indexaci\u00f3n<\/strong>: Determine qu\u00e9 columnas necesitan \u00edndices para el rendimiento de las consultas<\/p>\n<\/li>\n Requisitos de almacenamiento<\/strong>: Considere tipos de datos que optimicen el almacenamiento<\/p>\n<\/li>\n Particionado<\/strong>: Planifique para tablas grandes que puedan necesitar dividirse<\/p>\n<\/li>\n Cach\u00e9<\/strong>: Considere estrategias para datos frecuentemente accedidos<\/p>\n<\/li>\n<\/ul>\n 5. Caracter\u00edsticas espec\u00edficas del DBMS<\/strong> MySQL: Caracter\u00edsticas del motor de almacenamiento InnoDB<\/p>\n<\/li>\n PostgreSQL: Indexaci\u00f3n avanzada y soporte para JSON<\/p>\n<\/li>\n SQL Server: Capacidad de b\u00fasqueda de texto completo<\/p>\n<\/li>\n Oracle: Opciones avanzadas de particionado<\/p>\n<\/li>\n<\/ul>\n Conozca su DBMS<\/strong>: Cada sistema de bases de datos tiene peculiaridades y optimizaciones; aprende sobre ellas antes de dise\u00f1ar<\/p>\n<\/li>\n Piensa en el crecimiento<\/strong>: Considera no solo los requisitos actuales, sino tambi\u00e9n el volumen futuro de datos<\/p>\n<\/li>\n Indexa con inteligencia<\/strong>: Demasiados \u00edndices ralentizan las escrituras, demasiados pocos ralentizan las lecturas<\/p>\n<\/li>\n Documenta tus decisiones<\/strong>: \u00bfPor qu\u00e9 elegiste un tipo de dato o una estrategia de indexaci\u00f3n particular?<\/p>\n<\/li>\n Prueba con datos realistas<\/strong>: Si es posible, simula vol\u00famenes de datos del mundo real para probar el rendimiento<\/p>\n<\/li>\n<\/ol>\n Una de las caracter\u00edsticas m\u00e1s potentes de las herramientas modernas de modelado de datos es la capacidad de transitar de forma fluida entre diferentes niveles de modelado. Esto garantiza que los cambios realizados en niveles superiores se propaguen adecuadamente, permitiendo al mismo tiempo las refinaciones necesarias en niveles inferiores.<\/p>\n M\u00e9todo 1: Usando el men\u00fa contextual<\/strong><\/p>\n Haz clic derecho en el fondo de tu ERD conceptual o l\u00f3gico<\/p>\n<\/li>\n Selecciona\u00a0Utilidades > Transitar a ERD l\u00f3gico\/f\u00edsico\u2026<\/strong>\u00a0del men\u00fa emergente<\/p>\n<\/li>\n Se crear\u00e1 un nuevo ERD con entidades correspondientes<\/p>\n<\/li>\n<\/ol>\n M\u00e9todo 2: Usando la barra de acciones<\/strong><\/p>\n Selecciona\u00a0Transitar a ERD l\u00f3gico<\/strong>\u00a0o\u00a0Transitar a ERD f\u00edsico<\/strong>\u00a0de la barra de acciones en el lado derecho de un ERD<\/p>\n<\/li>\n Esto permite transitar desde un ERD conceptual a l\u00f3gico o f\u00edsico, o desde un ERD l\u00f3gico a f\u00edsico<\/p>\n<\/li>\n<\/ol>\n El Convertidor de Modelos permite a los usuarios convertir un ERD l\u00f3gico en un ERD f\u00edsico manteniendo la relaci\u00f3n de transici\u00f3n entre modelos. Despu\u00e9s de la transici\u00f3n, los dise\u00f1adores pueden realizar modificaciones como:<\/p>\n Renombrar entidades y columnas para ajustarlas a est\u00e1ndares t\u00e9cnicos<\/p>\n<\/li>\n Agregar entidades adicionales necesarias para la implementaci\u00f3n<\/p>\n<\/li>\n Ajustando relaciones seg\u00fan las restricciones del DBMS<\/p>\n<\/li>\n Incorporando optimizaciones de rendimiento<\/p>\n<\/li>\n<\/ul>\n No asumas que la automatizaci\u00f3n es perfecta<\/strong>: Aunque las herramientas pueden ayudar, revisa siempre los resultados de cualquier transici\u00f3n<\/p>\n<\/li>\n Agrega valor en cada nivel<\/strong>: No solo reproduzcas el modelo anterior, a\u00f1ade detalles adecuados para cada nivel<\/p>\n<\/li>\n Mant\u00e9n la trazabilidad<\/strong>: Documenta por qu\u00e9 se tomaron ciertas decisiones en cada nivel<\/p>\n<\/li>\n Est\u00e1 preparado para iterar<\/strong>: Podr\u00edas necesitar volver a un nivel superior si las restricciones t\u00e9cnicas requieren cambios significativos<\/p>\n<\/li>\n<\/ol>\n Comienza la fase de modelado conceptual participando ampliamente con los interesados del negocio. Aseg\u00farate de que todas las entidades y relaciones clave se capturen con precisi\u00f3n antes de pasar a modelos m\u00e1s detallados.<\/p>\n Consejo profesional:<\/strong>\u00a0Realiza talleres con interesados del negocio y t\u00e9cnicos juntos. Esto genera una comprensi\u00f3n compartida y reduce las brechas de comunicaci\u00f3n desde el principio.<\/p>\n Utiliza herramientas que apoyen las transiciones de modelos para mantener una trazabilidad clara entre modelos conceptuales, l\u00f3gicos y f\u00edsicos. Esto ayuda a comprender por qu\u00e9 se tomaron ciertas decisiones de dise\u00f1o y facilita modificaciones futuras.<\/p>\n Consejo profesional:<\/strong>\u00a0Crea un registro de decisiones que capture el razonamiento detr\u00e1s de las elecciones clave de dise\u00f1o en cada nivel.<\/p>\n Revisa y valida cada modelo con los interesados adecuados:<\/p>\n Modelos conceptuales<\/strong>\u00a0con usuarios del negocio<\/p>\n<\/li>\n Modelos l\u00f3gicos<\/strong>\u00a0con analistas de negocios y arquitectos t\u00e9cnicos<\/p>\n<\/li>\n Modelos f\u00edsicos<\/strong>\u00a0con administradores de bases de datos y desarrolladores<\/p>\n<\/li>\n<\/ul>\n Consejo profesional:<\/strong>\u00a0Crea listas de verificaci\u00f3n de validaci\u00f3n para cada nivel para asegurar la completitud y consistencia.<\/p>\n Mantenga una documentaci\u00f3n clara de supuestos, reglas de negocio y decisiones de dise\u00f1o en cada nivel de modelado. Esta documentaci\u00f3n resulta de gran valor durante la implementaci\u00f3n y el mantenimiento futuro.<\/p>\n Consejo profesional:<\/strong>\u00a0Utilice una herramienta de documentaci\u00f3n colaborativa que permita a los miembros del equipo contribuir y revisar decisiones.<\/p>\n El modelado de datos rara vez es un proceso lineal. Est\u00e9 preparado para iterar entre niveles a medida que surjan nuevos requisitos o se descubran limitaciones t\u00e9cnicas.<\/p>\n Consejo profesional:<\/strong>\u00a0Programa sesiones de revisi\u00f3n regulares para asegurarse de que el modelo permanezca alineado con las necesidades empresariales en evoluci\u00f3n.<\/p>\n Piense m\u00e1s all\u00e1 del simple almacenamiento de datos:<\/p>\n \u00bfC\u00f3mo se recuperar\u00e1n y analizar\u00e1n los datos?<\/p>\n<\/li>\n \u00bfQu\u00e9 requisitos de seguridad y privacidad existen?<\/p>\n<\/li>\n \u00bfC\u00f3mo evolucionar\u00e1 la base de datos con el tiempo?<\/p>\n<\/li>\n \u00bfQu\u00e9 puntos de integraci\u00f3n existen con otros sistemas?<\/p>\n<\/li>\n<\/ul>\n Las herramientas modernas de modelado de datos ofrecen funciones potentes para crear, transformar y mantener modelos. Invierta tiempo en aprender las capacidades de su herramienta.<\/p>\n Consejo profesional:<\/strong>\u00a0Muchas herramientas ofrecen pruebas gratuitas o licencias educativas; aproveche estas para encontrar lo que mejor funcione para su equipo.<\/p>\n El error:<\/strong>\u00a0Saltar directamente de los requisitos empresariales al dise\u00f1o f\u00edsico sin crear modelos conceptuales y l\u00f3gicos.<\/p>\n \u00bfPor qu\u00e9 es un problema:<\/strong>\u00a0Pueden pasarse por alto reglas de negocio importantes, y el dise\u00f1o resultante puede no reflejar adecuadamente las necesidades del negocio.<\/p>\n La soluci\u00f3n:<\/strong>\u00a0Dedique tiempo a cada nivel de modelado, incluso si cree que ya sabe c\u00f3mo deber\u00eda ser el dise\u00f1o final.<\/p>\n\n
Nivel 1: Modelo conceptual \u2013 Hablando el lenguaje del negocio<\/h2>\n
\u00bfQu\u00e9 es?<\/h3>\n
Caracter\u00edsticas clave<\/h3>\n
\n\n
\n \nCaracter\u00edstica<\/th>\n Descripci\u00f3n<\/th>\n<\/tr>\n<\/thead>\n \n P\u00fablico objetivo<\/strong><\/td>\n Partes interesadas del negocio, ejecutivos, gerentes de proyectos<\/td>\n<\/tr>\n \n Enfoque<\/strong><\/td>\n Qu\u00e9 datos se necesitan, no c\u00f3mo se almacenar\u00e1n<\/td>\n<\/tr>\n \n Complejidad<\/strong><\/td>\n Lenguaje simple y no t\u00e9cnico<\/td>\n<\/tr>\n \n Elementos<\/strong><\/td>\n Entidades principales y sus relaciones<\/td>\n<\/tr>\n \n Caracter\u00edstica especial<\/strong><\/td>\n Soporta generalizaci\u00f3n (por ejemplo, \u201cTri\u00e1ngulo es una clase de Forma\u201d)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Ejemplo visual<\/h3>\n
![\"Conceptual](\"https:\/\/www.booksofall.com\/wp-content\/uploads\/2026\/06\/conceptual_erd_27340.png\"\/)
<\/p>\nFunciones cr\u00edticas<\/h3>\n
\n
Nota importante sobre la generalizaci\u00f3n<\/h3>\n
Consejos y trucos para el modelado conceptual<\/h3>\n
\n
Nivel 2: Modelo l\u00f3gico \u2013 A\u00f1adiendo estructura sin detalles de implementaci\u00f3n<\/h2>\n
\u00bfQu\u00e9 es?<\/h3>\n
Caracter\u00edsticas clave<\/h3>\n
\n\n
\n \nCaracter\u00edstica<\/th>\n Descripci\u00f3n<\/th>\n<\/tr>\n<\/thead>\n \n P\u00fablico objetivo<\/strong><\/td>\n Analistas de negocios, arquitectos de datos, l\u00edderes t\u00e9cnicos<\/td>\n<\/tr>\n \n Enfoque<\/strong><\/td>\n Estructura detallada de datos, independiente de cualquier sistema de gesti\u00f3n de bases de datos<\/td>\n<\/tr>\n \n Complejidad<\/strong><\/td>\n Moderada, incluye atributos y tipos de datos<\/td>\n<\/tr>\n \n Elementos<\/strong><\/td>\n Entidades, atributos con tipos, relaciones detalladas<\/td>\n<\/tr>\n \n Caracter\u00edstica opcional<\/strong><\/td>\n Se pueden especificar los tipos de columna para facilitar el an\u00e1lisis<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Ejemplo visual<\/h3>\n
![\"Logical](\"https:\/\/www.booksofall.com\/wp-content\/uploads\/2026\/06\/logical_erd_27341.png\"\/)
<\/p>\nCaracter\u00edsticas clave de la modelizaci\u00f3n l\u00f3gica<\/h3>\n
\n
Consejos y trucos para el modelado l\u00f3gico<\/h3>\n
\n
Nivel 3: Modelo f\u00edsico \u2013 El plano maestro para la construcci\u00f3n de bases de datos<\/h2>\n
Qu\u00e9 es<\/h3>\n
Caracter\u00edsticas clave<\/h3>\n
\n\n
\n \nCaracter\u00edstica<\/th>\n Descripci\u00f3n<\/th>\n<\/tr>\n<\/thead>\n \n P\u00fablico objetivo<\/strong><\/td>\n Administradores de bases de datos, desarrolladores<\/td>\n<\/tr>\n \n Enfoque<\/strong><\/td>\n Detalles de implementaci\u00f3n t\u00e9cnica<\/td>\n<\/tr>\n \n Complejidad<\/strong><\/td>\n Alta, incluye especificaciones t\u00e9cnicas<\/td>\n<\/tr>\n \n Elementos<\/strong><\/td>\n Tablas, columnas con tipos de datos espec\u00edficos, restricciones<\/td>\n<\/tr>\n \n Cr\u00edtico<\/strong><\/td>\n Debe seguir las convenciones y restricciones del DBMS<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Ejemplo visual<\/h3>\n
![\"Physical](\"https:\/\/www.booksofall.com\/wp-content\/uploads\/2026\/06\/physical_erd_27342.png\"\/)
<\/p>\nConsideraciones clave para el modelado f\u00edsico<\/h3>\n
\nLa especificaci\u00f3n precisa de tipos de datos compatibles con el DBMS objetivo es esencial. Por ejemplo, VARCHAR(255) de MySQL frente a TEXT de PostgreSQL, o consideraciones entre DATE y TIMESTAMP.<\/p>\n
\nEvite palabras reservadas al nombrar entidades y columnas. Sea consistente con los patrones de nomenclatura (camelCase, snake_case, etc.) y aseg\u00farese de que los nombres sean claros y descriptivos.<\/p>\n\n
\n
\nAproveche las capacidades \u00fanicas del sistema de base de datos elegido:<\/p>\n\n
Consejos y trucos para el modelado f\u00edsico<\/h3>\n
\n
Transici\u00f3n entre modelos: garantizando continuidad y consistencia<\/h2>\n
Por qu\u00e9 importan las transiciones<\/h3>\n
C\u00f3mo realizar una transici\u00f3n<\/h3>\n
\n
\n
Qu\u00e9 ocurre durante la transici\u00f3n<\/h3>\n
\n
Consejos y trucos para las transiciones de modelos<\/h3>\n
\n
Mejores pr\u00e1cticas para un modelado de datos efectivo<\/h2>\n
1. Comienza con la participaci\u00f3n de los interesados<\/h3>\n
2. Mant\u00e9n la trazabilidad<\/h3>\n
3. Valida en cada etapa<\/h3>\n
\n
4. Documente supuestos y decisiones<\/h3>\n
5. Itere cuando sea necesario<\/h3>\n
6. Considere la visi\u00f3n general<\/h3>\n
\n
7. Use las herramientas adecuadas<\/h3>\n
Errores comunes que deben evitarse<\/h2>\n
1. Saltarse niveles<\/h3>\n
2. Sobrecargar los modelos iniciales<\/h3>\n