El modelo de datos.
La modelizaci贸n consiste en representar el problema realiz谩ndo m煤ltiples abstracciones para asimilar la informaci贸n de un problema y, de 茅sta manera generar un mapa donde est茅n identificados todos los objetos de la bbdd. Hay que tener en cuenta los siguiente conceptos:
● Casi con total probabilidad, la persona que realiza la modelizaci贸n es un profesional inform谩tico, pero no implica que sea un experto en las 谩reas que quiere modelizar. El futuro usuario de la bbdd ser谩 conocedor de los pormenores del neg贸cio y, a su vez, puede no tener conocimientos inform谩ticos.
● Hay que modelizar siguiendo unas directrices y est谩ndares para que el resto de la comunidad inform谩tica pueda entender y comprender lo escrito.
● Las bbdd estar谩n gestionadas por un sgbd que tendr谩 unas caracter铆sticas t茅cnicas, de esta manera, no se tratar谩 igual a la implementaci贸n de la bbdd a un sistema MySQL que a un sistema ACCESS.
En la actualidad se recurre a tres modelados principales:
Modelo conceptual:
Es un modelo ideal para comunicarse con el usuario no experto en inform谩tica ya que tiene la forma de expresar el dominio del problema al usuario de manera sencilla.
Modelo l贸gico:
Este modelo es m谩s t茅cnico que el anterior. Los conceptos suelen ser m谩s complejos y se suelen traducir directamente al modelo f铆sico que entiende el sgbd.
Modelo f铆sico:
Es el resultado de aplicar el modelo l贸gico a un sgbd concreto. Esta expresado en un lenguaje de programaci贸n tipo SQL.
La interacci贸n entre estos tres modelos es fundamental para un dise帽o de calidad teniendo tres fases de desarrollo entre ellos. Primero se negocia con el usuario el modelo conceptual. Segundo, se pasa el modelo conceptual al modelo l贸gico, realiz谩ndo una serie de transformaciones necesarias para adaptar el lenguaje al sgbd. Tercero se transforma el modelo l贸gico en f铆sico obteniendo de esta forma la bbdd final.
Diagrama entidad - relaci贸n.
Para el modelo conceptual se utilizar谩 el diagrama entidad - relaci贸n. 脡ste modelo consiste en plasmar el resultado del an谩lisis del problema mediante diagramas entidad - relaci贸n.
Este modelo fue propuesto por Peter P. Chen a mediados de los a帽os 70 para la representaci贸n conceptual de los datos y establecer relaciones entre ellos.
La notaci贸n es muy sencilla y permite representar el mundo real de forma que el usuario pueda validar si el modelo propuesto se ajusta a la resoluci贸n del problema.
Para conocer el modelo entidad relaci贸n deber谩s de conocer los siguientes conceptos:
Entidad.
Es cualquier objeto o concepto sobre el que se recoge informaci贸n. Se representa mediante un cuadrado.
Hay dos tipos de entidades: fuertes o d茅biles. Las segundas necesitan de las primeras para existir. Por ejemplo, una entidad transacciones, es una entidad d茅bil de otra entidad cuenta, ya que las transacciones van ligadas a una cuenta.
Las entidades d茅biles se representan mediante dos cuadrados (uno interno y otro externo).
Relaci贸n.
Una relaci贸n es una iteracci贸n entre las dos o m谩s entidades. Cada relaci贸n tiene un nombre que describe su funci贸n y suele utilizarse un nombre que puede significar muchas cosas y siempre en modo verbal (hacer, tener, calcular), por ejemplo. Se representan graficamente mediante un rombo y su nombre aparece en el interior. Suelen adem谩s, describir acciones entre las entidades.
Las relaciones se clasifican seg煤n su grado, es decir, seg煤n el n煤mero de entidades que participan en con la relaci贸n. As铆 en el ejemplo anterior la relaci贸n es de grado 2 porque participan dos entidades. Tambi茅n se llaman relaciones binarias.
Pero tambi茅n existen las relaciones ternarias, que son aquellas en las que participan tres entidades:
Y relaciones reflexivas, que solo interviene una entidad que se auto relaciona.
Existen tambi茅n relaciones de mayor grado que las ternarias, pero no las vamos a ver en este tutorial.
Participaci贸n.
La participaci贸n es el m铆nimo y m谩ximo que puede aparecer una relaci贸n en una entidad y viceversa. As铆 por ejemplo, fijate en la entidad - relaci贸n siguiente:
Un empleado puede trabajar en ning煤n proyecto (no lo tiene asignado o est谩 de vacaciones), o en uno o varios proyectos al mismo tiempo, por lo que la participaci贸n ser铆a 0, n (siendo n el n煤mero X que indica que es mayor que 1). Por el otro lado, un proyecto constar谩 de por lo menos 1 empleado y un m谩ximo de n. As铆 pues la participaci贸n se queda como ves en pantalla.
Observa que la participaci贸n se expresa en la entidad contraria.
Cardinalidad.
La cardinalidad es la participaci贸n de las entidades en una relaci贸n. Siempre se coge la m谩xima participaci贸n de cada entidad. As铆 en el ejemplo anterior, en empleado ten铆amos como m谩ximo n, y en proyecto tambi茅n n. Por lo tanto la cadinalidad ser铆a N:N (por nomenclatura no se repite la segunda N, sino que se pone una M para diferenciar). Adem谩s las 'ns' de las participaciones se ponen en min煤sculas y las 'ns' de la cardinalidad se ponen en may煤sculas por nomenclatura.
Para calcular la cardinalidad en relaciones no binarias (terciar铆as, o mayores), se tomar谩 una de las tres entidades y se combinar谩n con las otras dos (pero siempre se tomar谩n las de mayor rango). En las relaciones reflexivas, la misma entidad entra en juego y juega dos papeles diferentes. Para extraer las cardinalidades hay que extraer las poarticipaciones seg煤n los roles existentes.
En el ejemplo, la entidad empleado aparece con dos roles. El primer rol es como jefe y el segundo rol es como empleado subordinado. Las participaciones se calcular谩n preguntando como sigue:
驴Cu谩ntos subordinados pueden tener un jefe? Un jefe puede tener un m铆nimo de 1 y un m谩ximo de n (1,n).
驴Cu谩ntos jefes puee tener un subordinado? Un subordinado no tiene porque tener jefes o puede tener 1 (0,1), por lo tanto la relaci贸n ser铆a:
Atributos.
Los atributos de una entidad son las propiedades que la definen como entidad.
Puedes ver que cada entidad tiene una srie de atributos y que, en cada uno de ellos, uno de los atributos tiene una l铆nea negra sobre ellos. Eso indica que ese atributo es un atributo clave. Ese atributo identifica univ贸camente a la entidad. Por normalizaci贸n, todas las entidades fuertes deber谩n de tener un atributo clave.
Tambi茅n puedes ver que existe un atributo de relaci贸n. Este es propio de la relaci贸n y no puede ser cedido a las entidades que intervienen en la relaci贸n.
Los atributos se pueden clasificar seg煤n su tipo en:
● Atributos obligatorios.
● Atributos opcionales.
● Atributos compuestos.
● Atributos univaluados.
● Atributos multivaluados.
● Atributos derivados.
En los primeros el atributo debe de tomar un valor obligatoriamente, por lo general todos lo son a menos que sea opcional, ya que en el momento espec铆fico su valor puede ser indeterminado. Un atributo compuesto es aquel que puede subdividirse en m谩s atributos. Por ejemplo un atributo contacto tendr谩 otro atributo llamado movil, correo, email. Los atributos univaluados y multivaluados, podr谩n tener un 煤nico valor o varios valores respectivamente. Los atributos derivados son aquellos que se pueden obtener a ra铆z de otro atributo.
Dependencias en las entidades d茅biles.
Las entidades d茅biles dependen de las entidades fuertes mediante una relaci贸n. La relaci贸n que une ambas entidades tambi茅n es d茅bil, puesto que tambi茅n desaparecer谩 si desaparece la entidad fuerte. En este caso, la relaci贸n tiene una dependencia con la entidad fuerte que puede ser:
● Dependencia de existencia:
Este tipo de dependencia indica que los atributos de la entidad d茅bil no tienen sentido en la bbdd sin los atributos de la entidad fuerte con la que se relacionan.
●Dependencia de identificaci贸n.
Adem谩s de las propiedades de la anterior, la entidad d茅bil necesita a la fuerte para poder crear una clave.
Generalizaci贸n y especializaci贸n.
Se pueden dar circunstancias en las que necesitemos modelar entidades con subtipos que comparten gran parte de sus atributos con el general.
Existen 4 tipos de especializaci贸n:
● Exclusiva: Cada ocurrencia de la superclase solo puede materializarse en una de las especializaciones.● Inclusiva: Cada ocurrencia de la superclase puede materializarse simult谩neamente en varios subtipos.
● Total: Se produce cuando una de las ocurrencias de la superclase deben especializarse eobligatoriamente en una de las especialidades.
● Parcial: La entidad superclase no tiene porque materializarse en una de las especializaciones.
Bueno, creo que ya est谩 mas que completo la teor铆a. Ahora pasa a la zona de pr谩cticas para que podamos ir practicando con lo aprendido hasta ahora.