2. Modelado de datos2.1 Modelos de datos2.1.1 DefiniciónUn modelo es un conjunto de herramientas conceptuales para describir datos, sus relaciones, su significado y sus restricciones de consistencia. 2.1.2 Características
2.1.3 Metas y beneficios
2.1.4 Tipos de modelado de datosBasicamente son 3:
En las siguientes secciones se analizarán los aspectos relacionados con el modelado conceptual, más adelante y teniendo ya un modelo lógico se procederá a estudiar la representación física del mismo. 2.1.5 Modelado de Datos Conceptual2.1.5.1 Conceptos básicosAlgunos aspectos a considerar al momento de realizar el modelado/análisis
2.1.5.2 Modelos conceptualesExisten distintos tipos de modelos conceptuales: Basados en registros
Basados en objetos
2.2 Modelo Entidad-Relación2.2.1 DefiniciónGeneralmente todo modelo tiene una representación gráfica, para el caso de datos el modelo más popular es el modelo entidad-relación o digrama E/R. Se denomina así debido a que precisamente permite representar relaciones entre entidades (objetivo del modelado de datos). El modelo debe estar compuesto por:
2.2.2 Conjuntos de entidades y atributos
Ejemplos de entidades con sus atributos En el diseño se pueden considerar 3 categorías de atributos
NOTA: en la práctica es mejor considerar "siempre" a todos los atributos como simples y con valores simples 2.2.3 Llaves
Ejemplo: Teniendo los atributos de la entidad "persona"
2.2.4 Conjuntos de relaciones
Relación entre 2 entidades
Relación entre 2 entidades incluyendo un atributo en la relación 2.2.5 Diagrama E-RNotación empleada para elaborar modelos E-R 2.2.5.1 Diagramas E-R de relaciones entre entidadesDiagrama E-R mostrando una relación entre 2 entidades
Diagrama E-R mostrando una relación entre 2 entidades, con atributo en la relación Diagrama E-R mostrando una relación entre una misma entidad (útiles para elaborar jerarquías)
2.2.5.2 Categorías de atributosEjemplos de atributos derivados, compuestos y multivaluados NOTA: como se mencionó anteriormente NO es lo mejor el emplear estos atributos 2.2.5.3 Entidades débiles
Diagrama E-R mostrando una relación entre 2 entidades, una de ellas fuerte y otra débil 2.2.5.4 Guías de nombramientoEs importante mantener guías o reglas para poder tener una documentación uniforme y consistente de todos los datos.
2.2.5.5 CardinalidadesEn base al número de instancias involucradas en cada relación, éstas presentan un cardinalidad, que puede ser:
Relaciones (a)uno-muchos, (b)muchos-uno,(c) uno-uno 2.2.5.6 Múltiples relaciones entre 2 entidadesEs posible mantener muchas relaciones entre las mismas entidades, inclusive con distintas cardinalidades siempre y cuando cada una represente algo totalmente independiente de las otras. No se puede asumir que las relaciones se complementan o ni mucho menos que compartan atributos.
2.2.5.7 Especialización y generalizaciónEs el principio de "herencia" Las entidades de bajo nivel heredan todos los atributos de las entidades de mayor nivel
Especialización y generalización Nota: es importante mencionar que las entidades de menor nivel no poseen una llave primaria, únicamente la entidad de nivel superior es la que tiene entre sus atributos dicha llave y en consecuencia la "hereda" a las entidades especializadas. Restricciones en las generalizaciones De pertenencia al nivel más bajo
De pertenencia entre entidades en el nivel bajo
2.2.5.8 Principios de diseñoFidelidad: se debe crear siempre un modelo que satisfaga las necesidades del problema, no sirve un modelo correcto si no cumple con la realidad que se pretende representar. Evitar redundancia: una de las ventajas del diagrama e-r es que nos permite distinguir de una manera fácil y visual todos los entes y sus relaciones, de manera que es muy fácil identificar si un atributo se esta repitiendo en varias entidades o si una relación es innecesaria. Simplicidad: siempre hay que procurar hacer el modelo tan simple como sea posible (sin olvidar la fidelidad) de manera que sea fácil de entender, fácil de extender y fácil de implementar. Escoger los elementos correctos: es ocasiones es difícil identificar si una relación, elemento o atributo es correcto, para ello hay que analizar en perspectiva el diagrama y, por ejemplo si se observa una entidad con solo un atributo y que únicamente presenta relaciones de 1, entonces probablemente estamos hablando de un atributo y no de una entidad. Relaciones n-arias: Aún cuando se pueden presentar casos en los que una relación terciaria o n-aria parezca más conveniente, es mejor siempre pensar en términos de relaciones binarias únicamente. En el peor de los casos de que exista una relación n-aria forzosa, lo que se debe hacer es convertir esa relacion R en entidad E y corregir todas las relaciones que tenía R de manera que ahora esa nueva entidad se relacione con todas las entidades que anteriormente esta. Relación Ternaria Resultado de la conversión de relación de relación 3-aria a combinación de 2-arias
2.2.5.9 Otras notacionesLa notación mostrada en las secciones anteriores es solo una de las existentes, aún cuando todas en esencia representen el mismo concepto existen una gran variedad de simbologías y depende de cada persona el escoger aquella que más le convenga. Notación E/R (1) Ross, (2) Bachmann, (3) Martin, (4) Chen, (5) Rumbaugh
Por otro lado, Booch con su propuesta de un lenguaje de modelado unificado "UML" (Unified Modeling Language) abarca los aspectos de "relaciones" aplicables no solo al contexto de bases de datos sino al de programación y muchos otros más. Notación UML para modelos E-R 2.3 Conclusiones:
|