.

¿Cómo Diseñar una Base de Datos y no Morir en el Intento?

Como Disenar una Base de Datos

 

Cómo diseñar una base de datos y no morir en el intento

Hola a todos. Mi nombre es José León Cabel. Profesional  en Ing. De Sistemas y más de 18 años en el rubro del desarrollo e instrucción en lo concerniente a Tecnologías de Información, y ahora compartiendo con uds. algo que me apasiona: el diseño de base de datos. Este es el primer artículo de una serie de 4 que  tendrá como objetivo fundamental el aportar a los usuarios finales, que no necesariamente están ligados a temas de Tecnologías de Información (TI), pautas y conocimientos metodológicos acerca de cómo diseñar una base de datos , independientemente de la magnitud o alcances del  escenario real donde dichos usuarios se desarrollan.

¿Es la Información un recurso vital en la empresa moderna?

Como punto de partida me gustaría compartir con ustedes  un concepto de información que, mas allá de tecnicismos y esferas donde nos desenvolvemos, me parece uno de los más claros y de aceptación general: “Información es todo aquello que reduce nuestro nivel de incertidumbre acerca de algo que tenemos  necesidad de conocer”. Podemos poner varios ejemplos

a) Es sábado por la noche y quiero ver una buena película”. Pues lo primero que tenemos que hacer es informarnos en que sala de cine pasan la película, en que horarios, el costo de las entradas y comentarios acerca de la película (actores,  guion, director, etc.)

b) “Necesito hacer un viaje para relajarme y recargar energías”. Igual que el punto anterior, el interesado deberá buscar información sobre promociones turísticas, costos, que incluyen cada plan de viaje, hospedajes, entre otros  puntos de importancia.

c) “Me he dado cuenta que necesito seguir un diplomado en Marketing para desempeñarme mejor en mi  empleo”. Si esa es la necesidad, pues deberemos saber que instituciones ofrecen ese tipo de diplomados, su duración, horarios, si se dicta “on line” o presencial, los temarios o contenidos por curso, los expositores y la certificación que se obtendrá al finalizar el dicho diplomado. En pocas palabras, información.

Con estos 3 ejemplos de la vida diaria demostramos que tan importante es la información, la cual tiene como consecuencia final, que si la tenemos en un alto nivel de calidad y veracidad, nos asegura un altísimo porcentaje de éxito en la decisión que tomemos  y podríamos asegurar una excelente noche de cine, un reparador e inolvidable viaje de vacaciones o el de alcanzar una mejor proyección en nuestro desarrollo laboral.

Ahora si esto se da en esta pequeña escala la pregunta es ¿Qué será en las corporaciones grandes?

Imagine que es Ud. el responsable de definir el plan de expansión de una cadena de supermercados. ¿En base a que definiría en qué puntos de Lima o provincias aperturar un nuevo local? Lo más probable sería hacer un estudio de mercado con información acerca de mercados potenciales, competencia, ubicación y facilidad de acceso a los posibles nuevos locales, etc., además de conocer nuestras posibilidades de inversión en el plan de expansión que ambicionamos. Como nos damos cuenta, la información aquí ya es más detallada, especifica y requiere de un mayor cuidado en obtenerla. 

Dependiendo el nivel  administrativo donde se tomen las decisiones, la calidad y exactitud de la información varía. La siguiente gráfica así lo demuestra:

 

nivel de complejidad y exactitud de la informacion

En los niveles operativos y tácticos las decisiones son de tipo estructurada, es decir, los factores que permiten tomar la decisión son conocidos y se tiene una alta posibilidad de  éxito. Por ejemplo a que proveedor  solicitarle un producto o el monto a cobrarle a un cliente, según su cronograma de pagos. El cometer un error en este nivel, se puede manejar de manera correcta sin fuertes impactos en la empresa (claro está, si no son cotidianos).

En el nivel estratégico es donde las “papas queman”. Aquí  las decisiones son de tipo no estructuradas, lo cual quiere decir que los factores de éxito de la decisión  en cuestión no son del todo conocidos o muy dependientes de agentes externos y el nivel de riesgo es alto. Iniciar un nuevo rubro en la empresa, abrir nuevos locales, invertir en la bolsa, entre otros son claros ejemplos de este tipo de decisiones. Cometer errores aquí ya podría generar un fuerte impacto en la organización.

A manera de anécdota, esto último me hizo acordar a un colega mío que me hizo la siguiente pregunta: “La decisión de casarse como la definirías, ¿estructurada o no estructurada?”. Dejo la respuesta para cada uno de uds.

Les proporciono algunos links de interés que sugiero visiten para ampliar el tema de la importancia de la información en las empresas modernas

“El valor de la información en la empresa moderna”

http://www.edirectivos.com/articulos/1000031257-el-valor-de-la-informacion-en-la-empresa-moderna

“La información como recurso”

http://germanlescano.wordpress.com/2009/08/05/la-informacion-como-recurso/

“Importancia de la información en la empresa”

http://html.rincondelvago.com/importancia-de-la-informacion-en-la-empresa.html

 

Las bases de datos y su papel protagónico en el desarrollo de los Sistemas de Información

Bien, tras la introducción (un poco extensa, peo que considere importante), abordemos el tema de fondo. Las bases de datos. En mi experiencia en consultoría y desarrollo me he dado cuenta que hay una gran falencia en el diseño de la base de datos en muchas de las organizaciones donde los sistemas “funcionan mal”. El usuario final depende mucho de los reportes que los sistemas generan, y si la base de datos está mal diseñada, no le podemos pedir mucho al sistema. Por otro lado, es muy frecuente el uso de herramientas no adecuadas para la administración de los datos. Una gran cantidad  deusuarios emplea  hojas de cálculo como manejadores de base de datos, cuando en realidad no es lo más recomendable. Una hoja de cálculo jamás advertiría si estamos ingresando2 o 3 veces la información de un cliente o de un empleado. Cuando la información no es voluminosa no hay problema, pero ya cuando el volumen aumenta ahí empiezan a darse los errores y ya la situación se hace insostenible.

Recordemos que una base de datos es un almacén donde los sistemas de información guardan y recuperan datos, que luego dichos sistemas procesan para brindarle soporte a los usuarios finales en la toma de decisiones. Si el almacén está mal diseñado, sin adecuada organización, datos redundantes y errados, ya se podrán imaginar qué tipo de decisión tomaran los usuarios.  Una base de datos debe tener 3 aspectos fundamentales: Redundancia controlada, datos organizados y validados y permitir la facilidad tanto para almacenar como para recuperar datos.

Muchos de mis alumnos del curso de Excel para Expertos, cuando se tocaba el tema de acceso a base de datos  me preguntaban: “José, ¿Cómo puedo crear mi propia base de datos?” pues ahora, en estas 4 entregas, daremos las pautas para ello.

¿Hay una metodología para diseñar bases de datos?

Como para todos los aspectos tecnológicos hay una metodología, y en el caso del diseño de bases de datos dicha metodología se llama Modelo Entidad Relación (MER). Esta metodología, como su nombre lo indica, parte de identificar las entidades que son relevantes dentro del campo de acción que deseamos manejar y como se relacionan entre ellas. Propone el diseño de un modelo grafico que representa la forma como se diseñara la base de datos, al igual que un plano que especifica cómo se estructurara un edificio. Este modelo es totalmente independiente al software de manejo de base de datos a emplear, es decir, el modelo debe funcionar del mismo modo en SQL Server, Access, Oracle o cualquiera sea el software de gestión de base de datos a emplear.

Como toda metodología, hay herramientas para aplicarlas (ERwin, TOAD, Rational Rose, etc.), pero ya el manejo de estas herramientas va más allá del propósito de estos  artículos, que no pretenden caer en aspectos demasiado técnicos, sino al fundamento en si del tema: hacer un buen diseño de bases de datos.

Las Entidades

Una entidad es todo aquello de lo que se requiere manejar información dentro del ámbito del sistema que se piensa desarrollar. Las entidades pueden  ser personas, documentos, lugares físicos, objetos o incluso eventos propios del área en estudio. Si por ejemplo se desea hacer una base de datos para un sistema de gestión de citas a pacientes de un centro médico identificamos las siguientes entidades:

·         Paciente (persona)

·         Medico (persona)

·         Consultorio (lugar físico)

·         Cita (evento)

·         Empleado (persona)

·         Historial (documento)

¿Otro  ejemplo? Un sistema de gestión de libros  en una biblioteca. Identificamos a las siguientes entidades:

·         Libro (objeto)

·         Autor (persona)

·         Ejemplar (objeto)

·         Editorial (empresa)

·         Usuario (persona)

·         Empleado (persona)

·         Préstamo (evento)

·         Devolución (evento)

Obviamente dependiendo de la realidad específica a analizar podremos encontrar más entidades. No todos los sistemas de gestión de bibliotecas o de centros médicos  son iguales o requieren manejar la misma información, pero las entidades identificadas en los ejemplos son las que indudablemente no pueden faltar en dicho tipo de sistemas.

Bien, por ahora lo dejaremos ahí.  Pero antes de despedirme les propongo lo siguiente: si ud necesita diseñar una base de datos para su propio empleo pues lo invito a identificar que entidades existen dentro de su ámbito de acción. Si ud se desarrolla en una corporación muy grande recuerde no ser muy “generoso” y querer copar todo. Aplique aquel viejo refrán: “Divide y vencerás”. Segmente por actividades o procesos su análisis e identifique las entidades y anótelas en un papel o documento en su block de notas. Es el primer paso.

Segunda Parte:

Hola a todos. Mi nombre es José León Cabel.  En mi primera entrega conversamos sobre la importancia de la información en las actividades cotidianas, ya sea en nuestras vidas  personales como también en las organizaciones donde nos desempeñamos. Hoy en día la información se ha convertido en un recurso muy valioso y preciado, difícil de mantener y mucho más difícil de procesar, según la  envergadura de la realidad donde estamos involucrados.

Nos habíamos quedado conversando acerca de la mitología llamada Entidad-Relación, que nos permitirá diseñar lógicamente la base de datos y plasmarlo en un diagrama conocido como Diagrama Entidad-Relación. La metodología se llama así, porque identifica las Entidades pertenecientes al escenario a analizar así como sus relaciones.

El concepto de Entidad ya lo habíamos dado (todo aquello relevante para el sistema y de lo cual se que requiere registrar información). Sin embargo, antes de pasar al tema de Relaciones, es importante definir otro concepto esencial: Los atributos.

Los Atributos, características de las Entidades

Cada entidad tiene características que permiten identificarla, calificarla, clasificarla  o cuantificarla. Esas características se llaman Atributos. Por ejemplo en el caso de una base de datos para una clínica, el paciente sería una entidad importante y por tanto habría que identificar que atributos son relevantes conocer del paciente. Sin duda, sería necesario registrar su nombre, apellidos, sexo, fecha de nacimiento, DNI, dirección, teléfono, tipo de sangre, talla, peso, estado civil entre otros de importancia para un centro médico. Información como su experiencia laboral o formación académica no serian relevantes para un sistema de este tipo.

Si por otro lado el sistema fuera de Recursos Humanos, definitivamente que el trabajador seria una entidad relevante, y atributos como nombre, apellidos, sexo, fecha de nacimiento, dirección, teléfono, correo electrónico, DNI, experiencia laboral y formación académica serian importantes conocer, más no su tipo de sangre, peso o talla (aunque si hay empresas que registran dicha información de sus colaboradores).

Esto nos lleva a una conclusión. La identificación de los atributos depende del escenario donde nos ubiquemos, de tal forma que estemos seguros de que la información a registrar será la que realmente necesitamos para luego procesarla y obtener resultados valiosos.

El atributo Clave Principal

 Dentro de la lista de atributos identificados en una entidad, hay uno que debe ser el que permita ubicar a cada ocurrencia de la entidad. Llamamos ocurrencia a cada instancia de la misma  (por ejemplo, de la entidad Alumno, cada alumno es una ocurrencia de dicha entidad, como también en la entidad Producto, cada uno  de los productos es una ocurrencia o instancia de la misma). El atributo que nos permita acceder de manera única a una determinada instancia de la entidad es el llamado Clave Principal.  Hay 2 requisitos para que un atributo sea definido como Clave Principal:

 

  • Que tenga valores únicos en cada ocurrencia de la entidad
  • Que exista un valor para todas las ocurrencias de la entidad

 

Veamos algunos casos. En la entidad  Trabajador  podemos ubicar los siguientes atributos (asumiendo que son  empresas o personas jurídicas):

 

  •          Código del trabajador
  •          Nombres
  •          Apellido Paterno
  •          Apellido Paterno
  •          DNI
  •          Fecha de Nacimiento
  •          Sexo
  •          Estado Civil
  •          Dirección
  •          Distrito
  •          Teléfono Fijo
  •          Teléfono Celular
  •          Cargo
  •          Fecha de  Ingreso
  •          E_mail
  •          Estado (Activo o Inactivo)

 

De esta lista de atributos hay 2 que pueden ser Clave Principal: El código del trabajador o su DNI. Los demás atributos no cumplen los requisitos indicados. Si estuvo pensando que el correo pudo ser clave principal, pues se encuentran casos de trabajadores que no cuentan con un correo electrónico (o no tiene la necesidad de tener uno) o si pensaron que el teléfono fijo o celular podría ser clave también, pues puede ser que algunos trabajadores sean miembros de la misma familia y compartan el mismo número de teléfono fijo. Y si pensó  por un instante en el número de celular, pues simplemente pueden existir trabajadores que no tengan celular.

Por consiguiente de los  2 candidatos a ser clave principal se debe elegir solo uno, donde lo más probable es que sea el código del trabajador, quedando el DNI como una clave alterna, para ubicar a un trabajador, en caso de que  no se tenga su código. Esto lo vemos a diario en muchas empresas donde tenemos una afiliación, por ser clientes, alumnos, etc. Si no se tiene a la mano nuestro código, pues nuestra DNI servirá para identificarnos.

Refinando….Normalizando …..

El término “Normalización” es muy conocido en el ámbito de las base de datos. Si bien es cierto que el concepto se aplica  ya al modelo implementado para determinar su validez, podemos ir anticipándonos a ciertas cosas durante la construcción del modelo olgico.

Por ejemplo, en el caso de la entidad tTabajador expuesto  líneas arriba hay 2 atributos que pueden derivarse o convertirse en entidad: Distrito y Cargo . Bajo que premisa podemos afirmar esto?? . Por las siguientes razones:

a) Tanto el distrito como el cargo existen independientemente del trabajador. El hecho que el trabajador José León Cabel deje de pertenecer a la empresa, no quiere decir que el distrito de Surquillo deje de existir o que el cargo de Jefe de proyectos que el ostentaba  ya no exista más.

b) La cantidad de ocurrencias de distritos y de cargos amerita a que se deriven a una entidad para su mejor control y gestión. Solo en Lima existen más de 45 distritos y en una empresa pueden tranquilamente existir más de 10 cargos.

Por  tanto la lista de atributos  seria asi:

 

  •          Código del trabajador
  •          Nombres
  •          Apellido Paterno
  •          Apellido Paterno
  •          DNI
  •          Fecha de Nacimiento
  •          Sexo
  •          Estado Civil
  •          Dirección
  •          Código de distrito
  •          Teléfono Fijo
  •          Teléfono Celular
  •          Código de Cargo
  •          Fecha de  Ingreso
  •          E_mail
  •          Estado (Activo o Inactivo)

 

Tercera Parte:

Hola de nuevo. Mi nombre es José León Cabel.  En mi primera entrega conversamos sobre la importancia de la información en las actividades cotidianas, ya sea en nuestras vidas  personales como también en las organizaciones donde nos desempeñamos.

 

En la segunda, planteamos la necesidad de identificar atributos o características para las entidades,  siendo importante  tomar en cuenta a los que son necesarios dentro del ámbito del sistema. Además, establecimos la necesidad de incluir en cada entidad un atributo de tipo Clave Principal, factor de vital importancia en la búsqueda de información en una base de datos. Por último , establecimos también un refinamiento (Normalización) en cuanto a algunos atributos que podían convertirse en entidades, como en el caso del distrito y el cargo, quedando así el ejemplo final de la entrega anterior:

ENTIDAD TRABAJADOR

 

  •       Código del trabajador (Clave Principal)
  •          Nombres
  •          Apellido Paterno
  •          Apellido Paterno
  •          DNI
  •          Fecha de Nacimiento
  •          Sexo
  •          Estado Civil
  •          Dirección
  •          Código de distrito
  •          Teléfono Fijo
  •          Teléfono Celular
  •          Código de Cargo
  •          Fecha de  Ingreso
  •          E_mail
  •          Estado (Activo o Inactivo)

ENTIDAD  DISTRITO

 

  •          Código Distrital (Clave Principal)
  •          Nombre del distrito 

ENTIDAD CARGO:

 

  •          Código del cargo (Clave Principal)
  •          Descripción del cargo

 

En esta última entrega conversaremos acerca de las Relaciones entre las entidades y daremos la “estocada final” para el entendimiento de cómo se inicia el diseño de una base de datos. Allá vamos!!! 

Las Relaciones y como están  vinculadas las entidades 

En el modelo lógico (que es el ámbito donde nos ubicamos)  el termino RELACION  se orienta a la forma como 2  o más entidades están asociadas o vinculadas. Cuando la relación involucra a 2 entidades se llama relación binaria; cuando son 3 relaciones se llama relación ternaria y  así  por el estilo. Por ahora nos encargaremos solo de las relaciones binarias que son las más frecuentes. 

En este punto quisiera hacer una aclaración y desmitificar un concepto que vengo observado cómo se va mal interpretando por muchas personas. Veamos: 

El modelo lógico (que estamos diseñando) se basa en los requerimientos de los usuarios  de la base de datos, de acuerdo a lo que ellos necesitan almacenar en ella. Para elaborar el modelo lógico existe la metodología llamada “Modelo Entidad Relación” (MER), cuyo entregable es el gráfico llamado Diagrama Entidad Relación (DER). Bajo este punto de vista las relaciones son VÍNCULOS o ASOCIACIONES entre las entidades del modelo. 

Culminado el modelo lógico, este debe revertirse en el modelo físico, es decir, la base de datos propiamente dicha. Para ello, en lo que al  modelo físico se refiere, en la actualidad se emplea el modelo llamado “Modelo Relacional” que se basa en el principio MATEMÁTICO de relación el cual define a ésta como “conjunto de elementos”.  Ejemplo: cuando uno escucha por la radio “Daremos la RELACIÓN de ganadores del premio por el día de la madre” la palabra relación no implica vínculo, sino conjunto o grupo.  En el modelo físico entonces, la palabra RELACIÓN no implicavínculo o asociación, sino más bien conjunto y que para evitar confusiones con el modelo lógico se le conoce mejor como TABLA: Entonces podemos afirmar que el modelo  lógico permite implementar bases de datos que si son físicamente vistas en el modelo físico relacional, pueden ser construidas en cualquier manejador de base de datos  “relacional” como lo son casi todos los software de base de datos en la actualidad (Access, SQL Server, Oracle, etc.).  En el modelo físico , cada entidad y atributo  del modelo lógico se convertirán en tablas y columnas respectivamente.

En conclusión,  y justo hacia ahí apunta mi aclaración,  una base de datos  desde el punto de vista “físico” es relacional no porque sean “un conjunto de tablas relacionadas” como lo vengo leyendo y escuchando en muchos sitios, sino que es “relacional” porque se basa en el concepto MATEMÁTICO de relación el cual equivale a conjunto. Espero haber sido claro.

Nos enfocaremos en las relaciones ahora.

Para determinar el grado de una relación se emplea el término multiplicidad. Existen 3 tipos de multiplicidad. Sean las entidades A y B veamos lo siguiente:

 

  • De uno a uno: Cuando para una ocurrencia de la  entidad A le corresponde una y solo una ocurrencia de la unidad  B y viceversa. Ejemplo:

multiplicidad de uno a uno

  • De uno a muchos : Cuando para una ocurrencia de la entidad A existen una o más ocurrencias en la entidad  B y para cada ocurrencia de la entidad  B existe una y solo una ocurrencia en la entidad A. Ejemplo:

multiplicidad de uno a muchos

  • De muchos a  muchos: Cuando para una ocurrencia de la entidad A existen una o más ocurrencias en la entidad B y para cada ocurrencia de la entidad B existen una o más  una ocurrencias en la entidad A. Ejemplo:

multiplicidad de muchos a muchos

Nótese la simbología, la entidad se diagrama con un rectángulo, la relación con una línea recta y la multiplicidad con la rayita “perpendicular” indicando grado uno y  la “patita de gallo” indicando grado muchos. 

Consejos para identificar la multiplicidad 

Si tiene dificultades en establecer el grado de una relación  siga estos pasos:

  • Nombre cada entidad con un sustantivo en SINGULAR: Ejemplo: Alumno, Producto, Cliente, Factura. No use plural !!!
  • Identifique un verbo para la relación. Por ejemplo entre las entidades Cliente y Factura puede ser emplear  verbo “Generar”
  • Identificado el verbo, lea la relación en ambos sentidos y empezando de “UN(A)”. Por ejemplo  entre las entidades Cliente y Factura seria así :

Leyendo  de Cliente a Factura: “UN Cliente genera una o más Facturas”. Ahora leyendo de Factura a Cliente:”UNA Factura es generada por un solo Cliente”

 

En conclusión la relación entre Cliente con Factura seria de “Uno a Muchos” siendo el lado “Uno” Cliente y el lado “Muchos” Factura. 

identificar multiplicidad

Maneje con cuidado el factor “tiempo” en las relaciones: 

Por ejemplo, si tenemos las entidades Trabajador y  Cargo podemos decir que “Un trabajador ocupa un cargo y un cargo es ocupado por muchos trabajadores”. Esto sería si el análisis lo hacemos en el tiempo presente. Pero si lo hacemos “históricamente” hablando, la relación seria “Un trabajador HA OCUPADO uno o más cargos y un cargo es ocupado por muchos trabajadores!”. Nótese como el factor tiempo convierte una relación de UNO a MUCHOS en una relación de MUCHOS a MUCHOS. Siempre es bueno cuestionar las relaciones uno a muchos y si el factor tiempo es necesario en su sistema pues tome la segunda opción del ejemplo como grado para la relación entre Trabajador y Cargo. 

Migrando al modelo físico

Como ya adelantamos líneas arriba, el modelo lógico es la “receta” del pastel. Ud. el pastel lo puede hacer con la marca de horno que desee, pero si sigue al pie de la letra la receta y emplea ingredientes de calidad, es casi seguro que el pastel salga riquísimo. Aquí el pastel es la base de datos ya implementada en los “hornos con marca” Access, SQL Server u Oracle.

Recuerde que cada Entidad se convertirá en una Tabla de la base de datos física. Cada atributo de las entidades se convertirá en campos de la tabla (con sus respectivos tipos de datos según el manejador de base de datos que se elija). Y el atributo clave principal  será la Llave Primaria de la tabla. A continuación damos a conocer 2 reglas para refinar el modelo lógico antes de pasarlo al físico: 

Refinando las relaciones de Uno a Muchos:

“En una relación de uno a muchos el atributo clave principal del lado uno pasa como atributo de clave foránea a la entidad del lado muchos.”

Por ejemplo, en la relación Cliente-Factura, el atributo código del cliente que es clave principal de la entidad Cliente, pasaría a formar parte también de los atributos de la entidad Factura como una clave foránea. Esto permitirá saber cada factura que cliente la generó. 

Nota: Si la relación es de Uno a Uno, la clave principal de una entidad puede a pasar a formar de los atributos de la otra según sea más conveniente. Por ejemplo en la relación Asiento-Pasajero, el código de pasajero (clave principal de la entidad Pasajero) puede pasar a ser parte de los atributos de la entidad Asiento, y así se sabrá que pasajero ocupa cada asiento, o si se desea, el Nro. De asiento (clave principal de la entidad Asiento) puede pasar a formar parte de la entidad Pasajero para saber que asiento le corresponde a cada pasajero. 

Refinando las relaciones de mucho a muchos

“Una relación de muchos a muchos no se puede implementar en el modelo físico relacional. Por tanto, se debe construir una entidad  asociativa, que tendrá como clave principal una clave compuesta por las claves primarias de  cada entidad asociada. Podrá agregar más atributos a dicha entidad, de acuerdo a la necesidad planteada”

 

Por ejemplo, en la relación Alumno- Curso que se muchos a muchos se deberá reemplazar esta por una entidad asociativa (que se puede llamar Alumno_Curso) que tendrá como clave principal una clave compuesta por los atributos código del curso (clave principal de la entidad Curso) y el código del alumno (clave principal de la entidad Alumno). Puede agregar aquí los atributos de Examen Parcial, Examen Final, Nota de Proyecto de tal forma que esta entidad permita saber que cursos lleva cada alumno y que notas tiene en cada uno de ellos.

ejemplo relacion de mucho a muchos

Donde los términos PK se refieren a Primary Key (Llave Primaria) , FK a Foreign Key (Llave Foránea) y PFK Primary Foreign Key (Llave Primaria Foranea).

Adjunto un DER de un sistema de Ventas a manera de ejemplo:

relacion mucho a muchos en un sistema de ventas

Bien, hasta aquí llegamos. Espero que estos 3 avances les hayan permitido entender e iniciarse en el mundo del modelamiento de datos.  Recuerden que existen herramientas como el TOAD o ERWIN que permiten no solo diseñar los DER sino que también en base a ellos generar de manera automática la base de datos, pero esto vas mas allá del alcance de estas entregas.

Por último, sino cuenta con estas herramientas puede crear su modelo a mano, eso sí…lápiz, papel , borrador y muy buen humor para empezar todo de nuevo cuando sea necesario. 

Cualquier  consulta o asesoría en proyectos informáticos me pueden escribir a mi correo: [email protected] 

Saludos…..Dios los bendiga. Hasta la próxima.

 

 

 


AUTOR

JOSE OROSCO

Oracle Certified Professional 10g y Oracle Certified Professional 11g. Instructor registrado en Oracle University, Actualmente se desempeña como Administrador de Base de Datos para Banco Internacional del Perú y Consultor de Base de Datos. Ha participado en la implementación de proyectos de tecnología de información para empresas como Imarpe, Banco de Crédito, PNP y SUNARP.