SICI-4030 Base de Datos

SICI-4030Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico

OBJETIVOS • Explicar los diferentes tipos de diagramas brevemente para propósitos de posibles conversiones. • Diagrama de Chen • Notación de Tablas • Diagrama que utiliza el libro • Diagrama que se va a utilizar en el curso • Resolviendo Relaciones Muchos a Muchos • Cuando debe ponerse la barra UID en las relaciones • Ejercicios para Resolver • Comparación entre el diagrama del libro y el que se va a utilizar en el curso • Matriz de Relaciones

DIFERENTES TIPOS DE DIAGRAMAS Volver a los Objetivos

USO DE DIAGRAMAS • Existen muchos tipos de diagramas para crear los ERD (Entity Relational Diagram) de las Bases de Datos • No existe un estándar establecido de cuál formato debe utilizarse. • Para efectos del curso, vamos a utilizar una versión modificada de la que utiliza Oracle. • Para los trabajos que hay que entregar y los exámenes vamos a utilizar ese modelo modificado únicamente. • También vamos a examinar resumidamente los otros tipos de notaciones para familiarizarnos con ellos.

TIPOS DE DIAGRAMAS • Hoffer-Prescott-MacFadden Notation. • Visio Pro 2003. • Allfusion ERwin Data Modeler 4.1 SP1. • Sybase Power Designer 11.1. • Oracle Designer 10G • Modelo Chen (Modelo E-R creado por Peter Chen) • Versión de Oracle modificada (que vamos a utilizar en el curso)

EJEMPLOS DE DIAGRAMAS - 1 Símbolos Apéndice A

EJEMPLOS DE DIAGRAMAS - 2 Relaciones, opcionalidad y grado o cardinalidad Apéndice A

DIAGRAMA DE CHEN Volver a los Objetivos

Componentes del Modelo E-R (Chen) Entity Relationship Composite entity Attribute Como este modelo se utiliza con bastante frecuencia, se discute un poco más detallado que los demás. Yufei Yuan Course Web Site

Connectivity (opcionalidad) and Cardinality Connectivity 1 M Professor teaches Course (1,1) (0,3) Optional entity Mandatory entity Cardinality Estos conceptos se van a explicar más adelante. Se ponen aquí para tenerlo de referencia en caso de que tengan que trabajar con un diagrama que tenga este formato. Yufei Yuan Course Web Site

Diferentes Relaciones en el Diagrama de Chen Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

Ejemplo del modelo Chen para un Sistema Estudiantil de Registro Attributes Course Number Instructor ID Description Name Room Rank Teaches Course Instructor M 1 1 1 Advises M M CourseEnrollment Student 1 M Major Student Number Student Name Course Number Student Number Grade Yufei Yuan Course Web Site

Ejemplo del modelo Chen para un Sistema de Procesamiento de Ordenes Product Number Description Customer Name Unit price S Name S ID Address Products Customer 1 1 Salesman Placed 1 M prepared M S ID OrderLine M Order M 1 Date Order Number Customer Name Product Number Order Number Quantity Yufei Yuan Course Web Site

Ejemplo del modelo Chen para una Compañía de Construcción Project name Project Number Employee Number Employee Name Manager ID Hire Date Manages Project Employee 1 M 1 M M has Assigment M 1 Job class Assignment Number Hours Hour Rate Job Code Project Number Job Description Employee Number Yufei Yuan Course Web Site

NOTACIÓN DE TABLAS Volver a los Objetivos

Tables • Customers (CustomerName, Address) • Salesman (S-ID, S-Name) • Products (Prod#, Description, UnitPrice) • Orders (OrderNo, Date, S-ID, CustomerName) • OrderLine (OrderNo, Prod#, Quantity) Más adelante hablaremos de este tipo de notación. Yufei Yuan Course Web Site

DIAGRAMA QUE UTILIZA EL LIBRO Volver a los Objetivos

DIAGRAMA QUE UTILIZA EL LIBRO -1 Entity symbols Attribute symbols A special entity that is also a relationship Relationship symbols Relationship degrees specify number of entity types involved Relationship cardinalities specify how many of each entity type is allowed Basic E-R notation (Figure 3-2)

DIAGRAMA QUE UTILIZA EL LIBRO - 2 Sample E-R Diagram (Figure 3-1) Pág. 93 Este diagrama se lee al revés del que vamos a utilizar en el curso

DIAGRAMA QUE SE VA A UTILIZAR EN EL CURSO Volver a los Objetivos

DIAGRAMA ORACLE MODIFICADO • Ahora vamos a explicar el modelo que vamos a utilizar en el curso. • Es una variación de Oracle e integra símbolos de otros tipos de diagramas. • Será utilizado para los proyectos y el examen. • En la página(Moodle) hay un documento que tiene los diferentes símbolos y se pueden utilizar al momento de crear un ERD.

REGLAS PARA DIAGRAMAR • Las entidades van en una caja (rectangular) sin bordes. • Los nombres de las entidades se escriben en singular y en mayúsculas. • Cada nombre debe ser único. • Se puede poner un alias a una entidad que tenga más de un nombre entre paréntesis. • Los nombres de los atributos van en letra minúscula.

EJEMPLOS ENTIDADES EN DIAGRAMAS CLIENTE número nombre dirección teléfono crédito e-mail ESTUDIANTE número nombre edad genero seguro social departamento igs escuela procedencia ESTADIO (PARQUE) nombre dirección teléfono capacidad sillas capacidad carros

RELACIONES Como se mencionó anteriormente, es una asociación bi-direccional (ambas direcciones) e imprescindible entre dos entidades o entre una entidad y ella misma.

RELACIONES - SINTAXIS La sintaxis que vamos a utilizar para comprender las relaciones es: CADA entidad-1 nombre de la relación entidad-2 TIENE QUE SER O PUEDER SER Opcionalidad UNO O MÁS O UNO Y SOLO UNO Cardinalidad

RELACIONES - COMPONENTES • Nombre de la relación – Se utiliza una palabra que haga sentido al unir la relación entre dos entidades • Opcionalidad – Sólo se puede indicar “tiene que ser” o “puede ser” • Grado o Cardinalidad - Sólo se puede indicar “Uno o más” o “Uno y solo uno”

RELACIONES - EJEMPLOS DEPARTAMENTO - EMPLEADO Cada DEPARTAMENTO puede ser habitado por uno o más EMPLEADO(s) ESTUDIANTE - CURSO Cada ESTUDIANTE puede tomar uno o más CURSO(s) EDIFICIO – APARTAMENTO Cada EDIFICIO tiene que poseer uno o más APARTAMENTO(s)

RELACIONES - DIAGRAMAS Las relaciones se pueden diagramar de la siguiente forma: • Una línea une las dos entidades • El nombre de la relación va en minúsculas • El diagrama de Opcionalidad es: • Puede ser • Tiene que ser • El diagrama de Grado o Cardinalidad es: • Uno o más • Uno y solo uno

RELACIONES – DIAGRAMAS - EJEMPLOS DEPARTAMENTO - EMPLEADO Cada DEPARTAMENTO puede ser habitado por uno o más EMPLEADO(s) El nombre de la relación se pone arriba o abajo de la línea que une las dos entidades. DEPARTAMENTO id localización descripción EMPLEADO numero nombre seguro social habitado por

RELACIONES – DIAGRAMAS - EJEMPLOS ESTUDIANTE - CURSO Cada ESTUDIANTE puede tomar uno o más CURSO(s) ESTUDIANTE número nombre seguro social CURSO código semestre descripción tomar

RELACIONES – DIAGRAMAS - EJEMPLOS EDIFICIO – APARTAMENTO Cada EDIFICIO tiene queposeer uno o más APARTAMENTO(s) EDIFICIO id localización descripción APARTAMENTO número piso cantidad cuartos poseer

IMPORTANTE UNA RELACIÓN ES BIDIRECCIONAL. Por lo tanto hay que detallar y diagramar la relación también del otro lado. FINALMENTE LOS DIAGRAMAS QUEDARÍAN ASÍ:

RELACIONES – DIAGRAMAS - EJEMPLOS DEPARTAMENTO - EMPLEADO Cada DEPARTAMENTO puede ser habitado por uno o más EMPLEADO(s) Cada EMPLEADO tiene que estar asignado a uno y solo un DEPARTAMENTO DEPARTAMENTO id localización descripción EMPLEADO numero nombre seguro social habitado por estar asignado

RELACIONES – DIAGRAMAS - EJEMPLOS ESTUDIANTE - CURSO Cada ESTUDIANTE puede tomar uno o más CURSO(s) CadaCURSO puede ser tomado por uno o más ESTUDIANTE(S) ESTUDIANTE número nombre seguro social CURSO código semestre descripción tomar tomado por

RELACIONES – DIAGRAMAS - EJEMPLOS EDIFICIO – APARTAMENTO Cada EDIFICIO tiene que poseer uno o más APARTAMENTO(s) Cada APARTAMENTO tiene que ser poseido por uno y solo un EDIFICIO EDIFICIO id localización descripción APARTAMENTO número piso cantidad cuartos poseer poseido por

EJEMPLO DE UN ERD DE UN SISTEMA DE COMPRAS ORDEN número tipo fecha ARTÍCULO numero descripción peso emitida para incluido en almacenado en originado por el depósito para el originador de ALMACEN id descripción localización CLIENTE número nombre seguro social

TIPOS DE RELACIONES EXISTEN 3 TIPOS DE RELACIONES ENTRE LAS ENTIDADES • Muchos a uno (M : 1) • Muchos a muchos (M : M) • Uno a uno (1 : 1)

MUCHOS A UNOM a 1 o M : 1 • Tiene un grado de uno o más en una parte de la relación y de uno y solo uno en la otra parte. • Es el tipo de relación más común dentro de las bases de datos. • Las relaciones de muchos a uno que sea obligatoria en ambas partres es rara.

MUCHOS A UNO - EJEMPLO habitado por EMPLEADO numero nombre seguro social DEPARTAMENTO id localización descripción estar asignado 1 M∞

MUCHOS A MUCHOSM a M o M : M • Tiene un grado de uno o más en ambas partes. • También es un tipo de relación común. • Pueden ser opcionales en una o en ambas partes.

MUCHOS A MUCHOS - EJEMPLO CURSO código semestre descripción tomar ESTUDIANTE número nombre seguro social tomado por M ∞ M ∞

UNO A UNO1 a 1 o 1 : 1 • Tiene un grado de uno y sólo uno en ambas partes. • Este tipo de relación es raro y más aún si ambas partes son obligatorias. • Este tipo de relación podría indicar que ambas relaciones se puedan convertir en solo una.

UNO A UNO - EJEMPLO CARRO tablilla marca modelo MOTOR número descripción posee está asignado 1 1

CONVENCIONES DE LOS ATRIBUTOS • Los nombres de los atributos se crean pensando en el usuario (debe entenderlos) • EL nombre de la entidad no debe incluirse como parte del nombre del atributo • Deben ser específicos y descriptivos. (Ej. cantidad devuelta, fecha de nacimiento, etc.)

SÍMBOLOS PARA LOS ATRIBUTOS • * - Significa obligatorio (el atributo debe ser llenado por el usuario, no se puede dejar en blanco) • 0 – Significa opcional, el usuario no está obligado a llenar ese atributo. • # - Identifica un atributo que es UID (también hay que ponerle el símbolo * obligatoriamente). • (#) - UID segundario. Por ejemplo: seguro social.

UID’s EN RELACIONES • Cuando deseamos que un UID se utilice en otra entidad relacionada, utilizamos el símbolo: • Cuando deseamos incluir un UID como un campo foráneo (foreign key) en la otra entidad relacionada, utilizamos el símbolo: • IMPORTANTE: En la entidad que lleva uno de esos dos símbolos, en el ERD NO se le especifica el atributo.

UID’s QUE USAN RELACIONES • Una entidad puede ser identificada mediante una relación • Consideremos el siguiente ejemplo; En la Banca, a cada banco se le asigna un número único. Dentro de cada banco, a cada cuenta se le asigna un número único. ¿Cuál sería entonces el UID de la entidad CUENTA? BANCO #* número CUENTA #* número manejador de manejada por

UID’s QUE USAN RELACIONES (Cont) • Solución: Cada instancia de la entidad CUENTA se puede identificar por el atributo número y el BANCO específico al cual la cuenta pertenece. El número del BANCO es parte del UID de la entidad CUENTA BANCO #* número CUENTA #* número #* número_banco manejador de manejada por

UID’s QUE USAN RELACIONES (Cont) En este tipo de relación cualquier campo foráneo que provenga de otra entidad, no se puede representar (escribir) en esa entidad, por lo tanto se utiliza la barra UID para representar ese campo en la otra entidad. La barra UID indica que la relación con BANCO es parte del UID de CUENTA. BANCO #* número CUENTA #* número manejador de manejada por

UID SECUNDARIOS Y ARTIFICIALES Un UID secundario es aquel que nos puede permitir localizar una instancia en particular sin utilizar el UID ‘principal’. Por ejemplo en la entidad EMPLEADO, el número o código de empleado se puede utilizar ya que permite identificar por separado a cada instancia. Entonces, ¿Cuál podría se un UID secundario? EMPLEADO #* número nombre seguro_social fecha_nacimiento edad

SICI-4030 Base de Datos