Elaborado por: Alberto Bueno
ABCSOFT
2010 - 2021
INTRODUCCION
ELEMENTOS DE UN MODELO DE DATOS
Atributo
La Entidad
Clasificación de las entidades
Clasificación de los atributos
CLASIFICACIÓN DE LAS RELACIONES
Relación binaria
Relación n-arias
Relaciones múltiples entre objetos
Relaciones múltiples entre múltiples objetos
Indicadores asociativos del tipo de objeto
Clasificación de las relaciones
Restricciones de la cardinalidad
Generalización y especialización
Indicadores del supertipo y subtipo
Restricciones de la generalización y especialización
Diseño Top-down frente a Bottom-up
Dependencia funcional
Dependencia funcional completa
Dependencia funcional elemental
Notación del diccionario de datos
Diccionario de datos parte 1 revisar la documentación del dato
Diccionario de datos parte 2 normalizar los datos del documento
INTRODUCCION:
En mundo que actualmente vivimos el concepto de información se base que tanto se y como puedo sacarle provecho a ese conocimiento para mi bienestar; y que tanto me informo y el tipo de información es la que me interesa saber de lo que hay en nuestro mundo que nos rodea. La información viene a hacer un bien valioso para el hombre y para otro las puertas que abren el conocimiento de las nuevas tecnologías que existen. La información se base en el conjunto de datos ordenados que forma una idea o concepto de algún tipo de información; este conjunto de datos puede estar disperso por todas partes o agrupado en contenedores de bases de datos a los cuales acedemos de diferentes maneras. Puede ser a través de los sistemas de información, los sistemas de administración de datos o los sistemas de gestión de bases de datos, o a través del internet, la intranet, las redes sociales o todo medio de información que podemos encontrar para encontrar la información que necesitamos.
Los datos por sí solo no da ningún tipo de información, pero en su conjunto nos permite extraer la información que requerimos en la toma de decisiones que se hacen en los centros de trabajos, en la vida cotidiana, en las empresas, en los estados de los países, por lo tanto un modelo de datos bien definido, una base de datos estructurada y definida nos podrá dar la información acertada y precisa en la solución de los problemas en la organización y la vida profesional.
Los datos para su mejor administración se encuentra en banco de datos, llamados también base de datos, son datos que pertenecen a un mismo contexto de información y almacenado en contenedores para su posterior utilización por las estructura de la base de datos, que son las que define como se presenta la información solicitada por el usuario.
En este material se trata de de organizar a los datos, como una biblioteca organiza los libros para que el lector pueda encontrar los que busca como información; pero en este caso la biblioteca es de datos, documentos o textos llenos de información valiosa para el usuario y está organizada de tal forma que se puede encontrar fácilmente lo que se busca. Para ellos se crearán modelo de datos que permita su definición, organización, selección y que búsqueda sea fácil para todo usuario de esta gran biblioteca que es la base de datos.
De acuerdo a la definición de modelo, puede ser persona o ítem que posa para fotografías, dibujos, pinturas, esculturas y obtener un modelo artístico del prototipo de persona o de ítem ideal. También se puede decir es persona o ítem que muestra una prenda, ropa o accesorio con el fin de exhibirla a otros y puedan usarla como referencia.
Dentro del mundo de los datos viene hacer una descripción de cómo se representan los datos, en un sistema de información o en un sistema de gestión de base de datos. Además podemos decir como los datos se relacionan entre si y se comporta cuando estos son requeridos por los sistemas de información o los gestores de bases de datos.
Según el contexto, la palabra modelo puede referirse a. En la ciencia modelo es el resultado del proceso de generar una representación de elementos a fin de analizar esos fenómenos o procesos. En ciencias puras y, sobre todo, en ciencias aplicadas, se denomina modelo científico a una representación abstracta, conceptual, visual, de fenómenos, sistemas o procesos a fin de analizar, describir, explicar, simular, explorar, controlar y predecir esos fenómenos o procesos. En general un modelo permite determinar un output o resultado final a partir de un input o datos de entrada. Se considera que la creación de un modelo es una parte esencial de toda actividad científica.
En la física un modelo se puede definir para que te sirva para darte una idea de cómo es algo ejemplo: un globo terráqueo, un maniquí, un croquis, etc.
Desde tiempos inmemorables el hombre ha visto una sucesión de fenómenos naturales que han ocurrido en el mundo y estas ha podido ser descritas y descubiertas ya sea para comprenderlas, estudiarlas y predecirlas para futuros sucesos. La descripción de estos fenómenos se le llama dato. Los datos corresponden al registro de hechos acerca de algo que ha ocurrido y lo luego lo puedo utilizar para informarme del mundo en que vivimos y así poder incrementar nuestro conocimiento a través del dato.
Generalmente el dato nos sirve para poder tomar decisiones de hecho que ocurren en nuestro alrededor y así proceder correctamente con la solución del problema; cuando registramos el dato, este se registra además con su significado, ya que como lo expresamos en un lenguaje natural no los permite hacerlo. Por ejemplo “el auto de marca Mercedes Benn cuesta 50000 dólares”, para este caso se registra el valor (50000) y su significado o semántica (valor del producto auto de marca Mercedes Benn).
El dato es una representación simbólica de los números, de las letras, de expresiones algorítmica etc.), también se puede decir es un atributo o una característica de una entidad. El dato no tiene valor semántico (sentido) en sí mismo, pero si recibe un tratamiento (procesamiento) apropiado, se utiliza en el procesamiento de cálculos o toma de decisiones. Es de empleo muy común en el ámbito informático y, en general, prácticamente en cualquier disciplina científica.
En la programación, un dato es un tipo de valor identificado de una expresión general que describe las características de las entidades sobre las cuales se desarrolla un algoritmo. En la Estructura del dato, es la parte mínima de la información la que contiene un valor del cual se forma toda la información que requerimos para ser procesada y resolver una tarea o problema.subir
Un modelo de datos es básicamente una "descripción" de algo conocido como el lugar en donde se encuentra los datos y ese lugar de llama contenedor, en ellos los datos no está clasificados, no están ordenados y todos ellos están mezclados entre sí, un contenedor es algo en donde se guarda la información, así como de los métodos para almacenar y recuperar información de esos contenedores. Los modelos de datos no son cosas físicas: son abstracciones que permiten la implementación de un sistema eficiente de base de datos; por lo general se refieren a algoritmos, y conceptos matemáticos.
Algunos modelos con frecuencia son utilizados en las bases de datos Un modelo de datos define las reglas por las cuales los datos son descritos. Esta descripción, sin embargo, da una descripción completa acerca del significado de los datos y la forma en que serán usados. Las operaciones que se permiten efectuar con los datos deben ser establecidas por los algoritmos de la aplicación.
Generalmente las operaciones están relacionadas con la estructura de los datos y tienen validez en el contexto en que fueron definidos.
Los modelos de datos permite realizar abstracciones del mundo, permitiendo centrarse en los grandes aspectos, sin preocuparse de los detalles particularidades; así nuestra preocupación se centra en generar un esquema de representación, y no en los valores de los datos.
Los modelos de datos nos permiten capturar parcialmente el mundo, ya que es improbable generar un modelo que lo capture totalmente.
Sin embargo, se puede tener un conocimiento relativamente completo de la parte del mundo que nos interesa. Así, un modelo captura la cantidad de conocimiento tal que cumpla con los requerimientos que nos hemos impuesto previamente.
Los datos se pueden clasificar su estructura en datos simple y en datos compuestos; los datos simples según la estructura del dato, estos son indivisible, atómicamente son inseparables, no se puede descomponer, si se trata de dividirlo esto ya no serán datos, sino serán fracciones del dato, la cual no tiene ningún significado sobre el mismo.
Mientras que los datos compuestos, estos esta formados de los datos simples para su estructuración y significado dentro de un modelo de datos debidamente estructurado para el caso. Esta composición se lleva a cabo desde un inicio cuando los datos son capturados de su medio en donde se encuentra, o se puede componer o combinar cuando ya están capturados y se estructura un nuevo tipo de dato desde el contenedor para una nueva definición en la información.
Ejemplo: Cuando a una persona se le pregunta por su edad, esta responde una cantidad numérica, la cual puede estar formada de un o dos dígitos, pero si tratamos de separar la edad de dos dígitos uno de otro, tendríamos puestamente dos edades, la cual no correspondería a la persona, si no a otras personas, por lo tanto esto demuestra que la edad no se puede subdividir en otras partes.
Ejemplo: En muchos casos cuando iniciamos una tarea o actividad indicamos la fecha de inicio para lo cual anotamos el día luego el mes y finalmente el año. A dividir la fecha en sus partes elementales como son el día, tendríamos el número del día de una fecha cualquiera, el mes de una fecha cualquiera y el año de una fecha cualquiera. En otras palabras al descomponer en sus datos elementales simples, tendríamos tres datos simples; día, mes y año, que sería otros datos a ser utilizados.
ELEMENTOS DE UN MODELO DE DATOS
Los elementos de un modelo de datos son los que van a permitir diseñar un modelo de datos adecuado para una Base de Datos y estos sirvan para la definición de las tablas y su contenido, como también como estos se van a vincular entre sí.
ATRIBUTO
Los atributos se utilizan para definir a las entidades asignándoles propiedades descriptivas tales como id, edad o peso. No solo es posible definir atributos en las entidades sino también en las relaciones. Los atributos que están en las entidades pueden ser de dos tipos atributos candidatos o atributos simples; los atributos candidatos son los que puede asumir el concepto de claves y son los que están en la relaciones, mientras que los atributos normales o sea lo no candidatos son los que le pertenece a la entidad y describe las propiedades de cada entidad en un conjunto.
En particular, los atributos identificativos o claves son aquellos que permiten diferenciar a una instancia de la entidad de otra distinta. Por ejemplo, el atributo identificativo que distingue a un alumno de otro es su código de alumno.
Para cada atributo, existe un dominio del mismo, este hace referencia al tipo de datos que será almacenado o a las restricciones de sus valores que el atributo puede tomar (Cadenas de caracteres, números, solo dos letras, solo números mayores que cero, solo números enteros, etc.).
Cuando una entidad no tiene un valor para un atributo dado, este toma el valor nulo, bien sea que no se conoce, que no existe o que no se sabe nada al respecto del mismo.
Las entidades son los objetos que existen en el mundo real en forma física o abstracta y se les considera objetos principales sobre los que recogen algún tipo de información y generalmente denotan personas, ítem, lugares, cosas o eventos de interés. Las entidades aparecen reflejadas en el enunciado habitualmente como nombres.
Cada entidad pertenece a un conjunto, y se diferencia de las demás por el valor de sus atributos. Nótese que dos o más entidades diferentes pueden tener los mismos valores para algunos de sus atributos, pero nunca para todos.
Las entidades representan a un objeto del mundo real con existencia independiente, es decir, se diferencia unívocamente de cualquier otro objeto, incluso siendo del mismo tipo, o una misma entidad.
Un conjunto de entidades dentro de una entidad, tiene valores específicos asignados para cada uno de sus atributos, de esta forma, es posible su identificación unívoca.
Algunos Ejemplos de entidades:
Una persona. (Se diferencia de cualquier otra persona, incluso siendo gemelos).
Un automóvil. (Aunque sean de la misma marca, el mismo modelo, tendrán atributos diferentes, por ejemplo, el número de placa).
Una casa (Aunque sea exactamente igual a otra, aún se diferenciará en su dirección o de su número de registro de la propiedad).
Una entidad puede ser un objeto con existencia física como: una persona, un alumno, un auto, etc. (entidad concreta), o un objeto con existencia conceptual como: una matrícula del alumno, un horario de clases, un comprobante de pago, etc. (entidad abstracta).
Una entidad está descrita y se representa por sus características o atributos que lo define como tal. Por ejemplo, la entidad Trabajador puede llevar consigo las características: Código, Nombre, Apellido, Fecha de ingreso, Puesto, Sueldo, etc.
La relación entre entidades establece el área común en donde dos o más entidades comparten el mismo tipo de información a través de sus atributos comunes. Las relaciones representan asociaciones de las entidades en el mundo real entre una o más de ellas. Las relaciones se caracterizan porque se expresan por medio de un verbo. La relación de una entidad o con otra, se puede expresar como el interés que comparte entre ellas, a través de un o varios atributos comunes. Esto se puede expresar de la siguiente manera; dos personas son amigas o comparte gusto preferencias, porque a ambos les gusta las mismas cosas o tiene las misma preferencia, por eso mantiene una relación de amista, de compañerismo, de colega, de trabajo, etc. Y de esta forma es como se puede definir la relación entre las entidades.
Es la representación grafica de la relación de las entidades, también podemos decir que establece como las entidades se relaciona entre sí; como una entidad fuerte se relaciona con otra fuerte, o como una entidad fuerte se relaciona con una débil creando una dependencia entre ellas. En el modelo entidad relación no solo se indica la relación sino también el número de datos que se intercambia entre ellas, el sentido del intercambio de los datos y además los diferentes tipos de relaciones que existe entre las entidades. Vamos a empezar con algunas definiciones importantes para establecer el modelo entidad relación.
ENTIDAD: Es el objeto del mundo real al cual se desea obtener sus datos y guárdalo en un contenedor llamado base de datos, esta entidad representa al conjunto de entidades del tipo de objeto que existe en el mundo real. Además debemos distinguir que tenemos objetos abstractos y físicos y en el modelo de entidad relación se representa como un rectángulo.
Las entidades son el fundamento del modelo entidad relación. Por ejemplo, en un sistema bancario, los clientes y las cuentas bancarias de los clientes se interpreta como entidades. Las entidades pueden representar entes concretos, como una persona o un avión, o abstractas, como por ejemplo un préstamo o una reserva.
Clasificación de las entidades: Las entidades que existen en un modelo de datos se clasifican de acuerdo a como se define esta y a los atributos que los identifican; algunos por su naturaleza no depende de otras y otras dependen de otra entidad para su existencia y otras depende del modo de relación que tiene con la entidad independiente o cuando dichas entidades comparte atributos comunes en una operación de transacción o en una ocurrencia de intercambios de datos. De esta manera podemos definir que existen entidades fuertes o independientes y entidades débiles o dependientes de otras. Pero la clasificación que vamos hacer es que existen tres tipo de entidades, como se demuestra a continuación.
Entidades Fuertes: Se considera entidades fuertes aquellas que no depende de otras entidades para sus existencia en el modelo de datos; estas entidades nunca dependerán de otra entidad, más bien de estas entidades dependerán las otras para sus existencia en el modelo de datos. Estas entidades se diferencian de las otras, por que posee un atributo identificador, considerado como atributo clave. Además se les consideran entidades principales del modelo y generadoras de otras entidades y cuando se relaciona con otra entidad este transmites sus atributos claves a las entidades débiles. Dentro de la base de datos se les puede considerar también como entidades o tablas principales en otro caso como tablas maestras.
Entidades Débiles: Las entidades débiles se subdividen en dos grupos; las entidades parcialmente débiles y las entidades totalmente débiles. Estas entidades es muy probable que no posean atributos claves propios, sino que reciban los atributos claves de las entidades fuertes y de esa forma se les denomina entidades débiles; pero hay un grupo de entidades que si poseen atributos claves propios, pero reciben atributos claves de las entidades fuertes, esto lo hacen en el momento que se establece la relación entre ellas y es allí en donde comparte los mismos atributos ambas entidades, generalmente esto ocurre en una transacción de los datos de ambas entidades o cuando por medio de una ocurrencia existe un intercambio de datos. Tenemos entonces dos subgrupos; las entidades parcialmente débiles y las entidades totalmente débiles.
Entidades parcialmente débiles: Son las entidades que depende de otra entidad fuerte cuando solo comparte atributos comunes entre ellas, mientras no compartan atributos entre ella esta entidad se considera como una entidad fuerte, por que posee un atributo clave que la identifica como tal; pero recibe la clave extranjera de la otra entidad. Cuando estas entidades se relacionan en el área común intercambia atributos claves ambas, por lo tanto la relación que mantiene es agregación de un atributo clave a la otra entidad y solo ocurre esto en una transacción u ocurrencia entre ambas.
Entidades totalmente débiles: Son las entidades que depende de otra entidad fuerte en forma total para su existencia. Si la entidad fuerte no existe esta entidad tampoco existiría; la dependencia es absoluta y total; podemos decir que esta entidad forma parte de la entidad fuerte su relación es de composición y por lo tanto la relación es irrompible. Una de las características principales de esta entidad es que no posee atributos claves, sin más bien recibe el atributo clave de la entidad fuerte en el área común que comparte ambas entidades y así es como se establece la relación de dependencia entre ambas, a través de una relación de composición.
ATRIBUTO: En un modelo entidad relación los atributos forma parte importante para que las entidades se puedan relaciona entre ellas, ya que a través de los atributos identificadores o conocidos como claves se puede establecer la relación entre las entidades. El atributo es un tipo de datos que tiene la entidad, este tipo de dato define las características de la entidad, y así podemos saber cómo se compone la entidad y cuál es su esencia como tal. Los atributos entonces define las propiedades y características de la entidad; podemos decir por ejemplo un automóvil es una entidad que posee los siguientes atributos: marca, es el tipo de dato que define el atributo, Toyota que viene hacer la marca, es valor que asume el atributo cuando establece una característica de la marca del automóvil, y así podemos decir de color; es el atributo que define otra característica del automóvil y rojo el valor que el atributo tomo como una propiedad del automóvil, podemos decir que hay varios automóviles de la misma marca y color, pero describiendo las características del automóvil nos dirá que existe solo un tipo de automóvil y que no existe otro igual dentro de la entidad. La entidad en el modelo entidad relación se representa por medio de un círculo que rodea a una palabra y que está conectada a la entidad, de acuerdo al tipo de atributo esta representación puede variar.
Clasificación de los tipos de atributo: En el modelo de datos existen distintos tipos de atributos, como son: atributo monoevaluados, multievaluados, descriptores, identificadores, atributos compuestos, atributos simples, Almacenados o derivados, Posiblemente nulos, opcional.
Atributos Descriptores: no son "divisibles", es decir, son atómicos, representan un único dato para la instancia de la entidad que estamos modelando; por ejemplo: para el atributo "nombre" de la entidad alumno, el valor será "Juan Guido".
Atributo Monovaluados: Un solo valor. En su mayoría los atributos tienen un solo valor para una entidad en particular, y reciben el calificativo de monoevaluados. Por ejemplo, Edad, es un atributo monoevaluado de la entidad Persona por que una persona solo tiene una edad y esta varia con el tiempo.
Atributo Multivaluado: Varios valores. Hay casos en los que un atributo puede tener un conjunto de valores para la misma entidad; por ejemplo, un atributo color para un automóvil, o un atributo GradoUniversitario para una Persona. Los autos de un sólo color sólo tienen un valor de color, pero los de dos tonos pueden tener dos. De manera similar, una persona podría no tener grado universitario alguno, otra podría tener uno, y una tercera podría tener dos o más grados; así, diferentes personas pueden tener distintos números de valores para el atributo GradoUniversitario. Los atributos multivaluados, y pueden tener límites inferior y superior del número de valores para una entidad individual.
Atributos identificadores: Dentro de los atributos de una entidad, debe existir uno o más de un atributo que identifique a una instancia determinada de la entidad a la que pertenece, este o estos atributos reciben el nombre de identificadores o atributos clave.
Atributos Simples: No divisible, es decir es un atributo atómico, el cual no se puede dividir. Ejemplo: El atributo edad, su propiedad no tiene sentido dividirla, no tendrá significado para la entidad, ya que la concepción de este es un número indivisible.
Atributos Compuestos: Está conformado por un conjunto de partes que en el momento de dividirlas pueden formar otros atributos sin perder el sentido básico de la propiedad que está calificando la entidad. Un atributo compuesto se divide sólo por razones de manejo a nivel del lenguaje de consulta o por requerimientos del usuario, si no hay necesidad no se debe dividir ya que en algunas ocasiones se vuelve complejo el manejo de esta situación, es decir el atributo compuesto se trabaja como un atributo simple. Así se puede concluir que un atributo compuesto es la suma (concatenación) de los valores de los atributos simples que lo conforman.
Atributos Derivados: Son atributos cuyo valor depende de los valores de otros atributos o entidades. Ejemplo: el atributo sueldo pude derivarse a partir del cálculo de los siguientes valores: horas trabajadas por el costo de hora de trabajo. Otro ejemplo la edad de una persona es casi siempre un atributo derivado de la fecha de nacimiento del individuo.
Atributos Almacenados: Son los atributos que cuyo valor guardan una cantidad que se utiliza para realizar cálculos con otros atributos en otra entidades o en la misma entidad. Ejemplo fecha de nacimiento, nacionalidad (de una película)
Atributos Nulos: Cuando un atributo se puede dejar “en blanco”. Es muy raro que u atributo de una entidad este en blanco; pero en ocasiones especiales este atributo puede estar en blanco, vale decir cuando los datos que se almacenan en este atributo no tiene relevancia para la entidad. Por ejemplo, en una compra de productos en donde el producto no tenga un descuento, pero otro si lo tenga entonces la cantidad que le corresponde a este atributo será cero o valor nulo.
Atributos Opcionales: Este tipo de atributo se le considera así por la característica que puede asumir, dado un conjunto de atributos que tiene la entidad y uno de ellos los datos se puede omitir porque la entidad considera que ese atributo en particular no es necesario almacenarlo como tipo de dato, ya que es probable que no existe el dato para ese atributo. En una entidad en donde se solicite a un segundo número de teléfono a una persona y esta no tuviera, entonces el atributo quedaría vacio, pero se considera que no todas las personas pudieran tener un segundo número de teléfono; o en su defecto una empresa a la cual se le solicita el número de fax y esta no la tuviera el atributo quedaría también vacio; por lo tanto este sería un atributo opcional.
Atributos complejos: Son atributos compuestos o multivaluados anidados de una manera arbitraria los cuales forma lista, conjuntos, etc.
Atributos Claves: Los atributos claves son los identifica al tipo objeto que está dentro de un conjunto de entidades, también es la que determina el orden los datos de la entidades estarán clasificados. El atributo clave suele ser el atributo que sirve para vincular dos más entidades; para el caso de las entidades débiles el atributo clave viaja hacia la entidad débil o parcialmente débil.
RELACION
Es el área común en donde dos o más entidades comparten los mismos atributos, estos atributos que comparten son atributos claves, es de ahí que se tiene los diferentes tipos de claves que puede asumir una entidad. Porque se le llama área común, porque allí convergen los atributos que permite el enlace entre las entidades, allí también comparte los mismos atributos de todas las entidades. La relación entre entidades se puede representar por medio de un rombo y de acuerdo al tipo de relación este puede variar; porque tenemos relaciones entre entidades fuertes, relaciones entre una entidad fuerte y otra débil.
CLASIFICACION DE RELACIONES ENTRE ENTIDADES
Las entidades se relaciona para compartir datos y estos datos convertirse en información, las relaciones pueden hacer entre dos entidades o más entidades; ahora veremos como estas entidades se pueden relacionar.
RELACIÓN BINARIA: Esta relación existe cuando solo dos entidades se relacionan para compartir datos a través de los atributos, puede ser entre una entidad fuerte y otra débil o entre una entidad fuerte y otra fuerte. Esta relación es la más común entre las entidades y es la que mayormente se usa para relacionar las entidades.
RELACION N-ARIAS: Se le conoce así a las relaciones que existe con más de dos entidades. Una de estas relaciones es la relación ternaria y la otra es la relación cuaternaria.
Relación ternaria: Esta relación es cuando tres entidades se relacionan a través de un área común y comparten los mismos datos, a través de los atributos claves de ellas. Pero cuando ocurre este tipo de relación entre las entidades, porque no es común este tipo de relación como lo mencionamos en el párrafo anterior; esto llega a pasar cuando la relación entre las entidades la cardinalidad es de muchos a muchos; esto en la parte lógica se puede representar de esa manera; en la parte física no, por lo tanto de obtiene una tercera entidad que tiene los atributos claves de ambas y esta entidad viene hacer una entidad dependiente de las otras dos. Otra forma de presentarse este tipo de relación es cuando la relación se convierte en entidad, por lo tanto se crea una tercera entidad; ahora bien porque una relación se convierte en entidad, cuando por razones de integridad de la información o por que la información que existe en la relación debe ser guardada, en ese caso la relación se convierte en entidad.
Relación Cuaternaria: Esta es una relación que existe entre cuatro entidades, en donde la relación de las cuatro entidades converge en un área común y se intercambia los atributos y esta formar se establece el vínculo entre ellas. Este tipo de relación no es muy común entre las entidades por lo tanto no es muy usado como un tipo de relación.
La relación reflexiva es un tipo de relación en la cual la entidad se asocia a sí misma, cuando tiene que especificar un roles que la entidad; este tipo de relación también se le conoce como relación recursiva. Los nombres de rol se deben usarse, sobre todo, en los tipos de relación reflexivos, para evitar ambigüedades. Muchas veces es importante indicar el rol, es decir, la función que desempeña un tipo de entidad en una relación. Los roles suele ser implícitos y no se especifican, pero pueden ser útiles si se necesita aclarar el significado de una relación. Un caso típico es cuando existe una relación reflexiva.
Relaciones mÚltiples entre los objetos
Este tipo de relación se presenta cuando existe más de una relación entre los objetos (entidades). Estas relaciones muestran una relación distinta entre ambos objetos. Una de ella ocurre en un determinado tiempo y la otra ocurre en otro determinado tiempo, pero ambas relaciones son se presenta a la vez, y esto ocurriera tendríamos una incoherencia en la información y una falta de integridad de los datos. Tenemos las siguientes entidades PACIENTE y MÉDICO; al parecer es algo rebuscado lo obvio; cada vez que el paciente va a donde el médico este le extiende un comprobante por sus honorarios; pero también implica que el paciente asista a su médico por tratamiento que tenga que seguir o simplemente a una consulta, y obviamente tenga varias consultas o tratamientos cómo evolucione su enfermedad. Esto implica que cada vez que valla al médico este lo trate y luego de entregue un comprobante por sus honorarios; como también es posible solo asista a su tratamiento y no se le cobre, y solo se cobro en la primera consulta. Esto indica que la relación de recibir comprobantes está completamente separada de la relación de tratamiento.
RELACIONES MÚLITIPLES ENTRE MÚLTIPLES OBJETOS
En una situación más común es ver múltiples relaciones entre múltiples objetos, esta ocurre cuando un objeto (entidad) se relaciona con otras dos, formado una relación ternaria, pero cada una en forma individual y se realiza en diferentes tiempos, por lo tanto esto no sucede a la misma vez. Tenemos las siguientes entidades CLIENTE, VENDEDOR, CORREDOR DE INMUEBLE, ABOGADO DEL CLIENTE Y ABOGADO DEL VENDEDOR, para la compra venta de una casa. La relación y sus tipos de objetos deben leerse como una unidad. La relación se puede describir desde la perspectiva de cualquiera de los tipos de objetos participan, y todas esas perspectivas son validas. De hecho, el conjunto de todos estos puntos de vista es el describe completamente la relación. Por ejemplo en la figura puede vérsela relación de negociación de precios en cualquiera de las siguientes tres formas:
- El corredor de inmuebles negocia el precio entre el cliente y el vendedor.
- El cliente negocia el precio con el vendedor, mediante el corredor de inmueble.
- El vendedor negocia el precio con el cliente, mediante el corredor de inmueble.
INDICADORES ASOCIATIVO DEL TIPO DE OBJETO
Una notación especial en el diagrama E-R es el indicador asociativo del tipo de objeto; representa algo que funciona como objeto y como relación. Otra manera de ver esto es considerar que el tipo asociativo de objeto representa una relación acerca de la cual se desea mantener alguna información. En siguiente caso en donde tenemos a un CLIENTE y un PRODUCTO, el cliente compra un producto o varios productos dependiendo del momento de la compra. La relación que existe entre estas entidades que la vincula entre sí es la de comprar, supóngase que se necesite más datos que recordar o que saber de la relación de compra, como por ejemplo la fecha de la compra, la hora de la compra, estos datos no pueden estar en la entidad CLIENTE, ni tampoco en la entidad PRODUCTO, como son datos relativamente de la compra, entonces estos datos deberán estar en la nueva entidad compra, ya que la relación mantiene otros datos pasara a ser una entidad y esta se conectará con los otros objetos CLIENTE y PRODUCTO y la relación sin nombre. Esto pretende indicar que COMPRA funciona como:
- Un tipo de objeto, algo acerca de lo cual se desea almacenar información. En este caso, se desea recordar la fecha de la compra, la hora de la compra y descuento que se realizo al cliente.
- Una relación que conecta los dos tipos de objetos CLIENTE y PRODUCTO. Lo significativo aquí es que CLIENTE y PRODUCTO se mantienen solos. Existirán con o sin la compra.
Una COMPRA, por otro lado, obviamente depende para su misma existencia del CLIENTE y del PRODUCTO. La relación aparece como resultado de una relación entre los otros dos objetos con los cuales está vinculado.
En la figura como puede apreciar la relación no tiene nombre; esto se debe a que el indicador asociativo también tiene el mismo nombre de la relación.
Las relaciones es la forma de vincular a las entidades y están puedan compartir los datos a través de los atributos claves, pero hasta ahora no hemos dicho como se comparten los datos. Cuando dos entidades se vinculan a través de una relación esta intercambia datos en un área común y esto puede suceder en diferentes ocurrencias en distintos tiempos, en cada ocurrencia se pueden intercambiar un solo dato entre las entidades o varios datos entre ellas. Podemos decir que por ejemplo un CLIENTE compra un solo PRODUCTO en una ocurrencia; en otro momento el CLIENTE compra varios PRODUCTOS; ese forma decimos que los datos fluyen entre las entidades y podemos afirmar que el mínimo dato que intercambia es uno y el máximo es varios; a eso nos referimos a la cantidad de datos que intercambia, y eso se conoce como la cardinalidad entre las entidades. Algunos datos viajan en un solo sentido; esto sucede con las entidades débiles; ya que estas entidades solo reciben en algunos casos datos y otros no, pero las que reciben datos a través de los atributos son las totalmente débiles y a eso le llamamos ordinalidad. Cuando queremos indicar como se vincula las entidades con su respetiva relación lo hacemos a través de una oración, en donde el verbo viene hacer la relación y además indicamos la cantidad de datos que se pueden intercambiar a eso se le conoce como mapeo.
CLASIFICACION DE LAS RELACIONES
Cuando dos entidades o mas se vinculan a través de una relación, para el intercambio de datos entre ellas, esta relación puede ser de no entidad y de entidad, y en algunos casos simplemente una relación de comunicación en donde las entidades relacionadas no tenga una relación de integridad referencial entre ellas, ahora ¿Qué es integridad referencial?, pues eso lo explicaremos líneas abajo.
Relación de Entidad: Esta es una relación que existe entre una entidad fuerte y otra entidad débil; en donde el atributo clave se traslada al área común de la relación entre las entidades, y así la entidad débil se convierte una entidad dependiente de la fuerte y mantiene una relación de composición.
Relación de No Entidad: Esta es una relación que se presenta, cuando las dos entidades fuertes se vinculan entre sí en una relación en donde ambas intercambia datos, en donde los atributos claves de ambas entidades se traslada al área común de la relación, pero ninguna pierde su condición de entidad fuerte, pero cabe indicar que una de ella necesariamente depende de la otra para realizar una ocurrencia en una operación. Este tipo de relación convierte a una de ella en una entidad dependiente de la otra y mantiene una relación de agregación.
Relación de Comunicación: Esta relación solo se puede presentar en entidades fuertes, pero no siempre entre los atributos claves de ambas, la relación consiste en pasar datos de una a otra entidad, por lo general el que recibe los datos en la entidad principal para completar datos, en esta relación no existe cardinalidad entre ambas y tampoco integridad referencial.
Integridad Referencial: Hemos hablado de este término ya anteriormente, es una propiedad que utilizan los sistemas de gestión de bases de datos; pero que es, que significa y para que lo usamos. Esta propiedad sirve para mantener los datos íntegros entre las entidades que luego se puedan realizar las operaciones de actualizar, modificar o borrar, y estas operaciones se puedan realizar en cascada. Otra propiedad y la principal presenta la integridad referencial es que siempre la relación con otras entidades sean validas y que exista en la base de datos, y además implica que todos los datos sean correctos, que no existe la duplicidad de datos, datos perdidos y relaciones mal resueltas. También se puede considerar como un sistema de reglas que utilizan las bases de datos en donde las entidades o tablas relacionadas en donde los datos no se borren o cambia en forma accidental produciendo errores de integridad.
Cuando las entidades se vinculan entre sí a través de una relación, estas intercambian datos, este intercambio se hace desde la entidad fuerte hacia la entidad débil; pero este intercambio se realiza dependiendo de la ocurrencia entre ellas, y cada ocurrencia se lleva en diferentes momentos. Y tenemos que algún momento solo se intercambia un solo dato y en otros momentos se intercambian varios datos. Por lo tanto eso es medido por la cardinalidad. Para ello realizaremos un ejemplo entre dos entidades.
Tenemos una entidad CLIENTE y una entidad PRODUCTO, están se relacionan de la siguiente manera: un CLIENTE compra un PRODUCTO
Como vemos en el gráfico el CLIENTE compra PRODUCTO, pero cuantos compra, cuando compra y como los compra.
Un CLIENTE compra un solo un PRODUCTO, estamos hablando de una relación de 1 a 1. Un CLIENTE compra ningún PRODUCTO, estamos hablando de una relación de u a ninguno. Un CLIENTE compra varios PRODUCTOS, estamos hablando de una relación de uno a varios. También podemos decir lo siguiente. Varios CLIENTES compra uno solo un PRODUCTO, estamos hablando de una relación de varios a uno. Varios CLIENTES compran varios PRODUCTOS, estamos hablamos de una relación de varios a varios. Ningún CLIENTE compra uno PRODUCTOS, estamos hablando de una relación de ninguno a uno. Esto se puede resumir en la siguiente tabla:
Un CLIENTE compra un solo un PRODUCTO |
1:1 |
Un CLIENTE compra varios PRODUCTO |
1:N |
Un CLIENTE compra ningún PRODUCTO |
1:0 |
Varios CLIENTES compran varios PRODUCTOS |
N:N |
Varios CLIENTES compra uno solo un PRODUCTO |
N:1 |
Ningún CLIENTE compra uno PRODUCTOS |
0:1 |
Varios CLIENTE compra ningún PRODUCTO |
N:0 |
La cardinalidad que tenemos en la relación: 1:1, 1:N, 1:0, N:N, N:0.
Cuando una entidad se relaciona con otra entidad en un área común, están intercambian datos, pero como sabemos la entidad débil recibe el atributo de la entidad fuerte, por lo tanto el dato del atributo clave viaja desde la entidad fuerte hacia la entidad débil, por lo tanto la ordinalidad establece en qué sentido viajan los datos de los atributos claves hacia la otra entidad. En otras ocasiones los datos viajan en ambos sentidos, desde una entidad fuerte hacia una entidad parcialmente débil, como también desde una entidad parcialmente débil hacia una fuerte.
Las relaciones nos permiten tratar las asociaciones como entidades relacionadas. Los mapeos, sin embargo, no ven en su totalidad el conjunto. Nos permiten, es cambio, iniciar desde simplemente una parte del todo y atravesar (o más bien mapear) hasta llegar a la otra parte de ese todo. El tipo de relación, como concepto y término, es de uso común. La noción de mapeo entre tipos de objetos también es común. Sin embargo, el mapeo determina el concepto de relación que existe entre los objetos.
Hemos dicho que entre las entidades existe un vínculo cuando estas se relacionan, y para establecer esa relación se lleva a cabo a través de los atributos claves que tienen las entidades, pues existen cuatro tipo de claves o llaves que permiten el vínculo entre las entidades y/o el ordenamiento de los datos en las entidades y estas son las siguiente:
- Llave Principal: Conocida también como llave principal; esta llave tiene todas las entidades fuertes y la usan para vincularse con otra entidad en una relación. La clave principal viene hacer un atributo clave y se da como consecuencia de las claves candidatas que tiene una entidad; además por esta clave es que la entidad se identifica y se clasifica los datos de la entidad.
- Llave Foranea: Esta clave es conocida también como clave extranjera, es la clave que es recibida por una entidad débil cuando esta se vincula en una relación de entidades, a través de esta clave los datos de la entidad fuerte fluyen a la entidad débil y así existe el intercambio de datos y la dependencia entre una entidad fuerte con una entidad débil.
- Llave Alternativa: En algunas entidades en donde es posible establecer varios atributos candidatos para claves, las claves alternativas son esos atributos candidatos que pueden ser utilizado como clave. Esto se hace cuando la clave principal no se puede utilizar como tal para la clasificación de los datos de una entidad, ese caso entra en funcionamiento las claves alternativas para clasificar a la entidad u ordenar a la entidad en una nueva forma de clasificación de los datos de la entidad.
- Super Clave: Esta clave se utilizan mediante la combinación de dos o más atributos, para crear una nueva clave de clasificación de la entidad. No es un tipo de clave se utilice siempre, solo cuando las claves anteriores no sirva para tal caso. En una entidad en donde no se encuentre una clave principal o no existan claves alternativas y no se pueda clasificar a la entidad, ese caso se crea la super clave.
RESTRICIONES DE LA CARDINALIDAD
Cuando se realiza la relación entre entidades, estas tiende a compartir datos entre ellas, pero algunas veces los datos que comparten tiene un límite o un tope que los limita a una cierta cantidad de datos a intercambiar. Como hemos vistos en la cardinalidad, las ocurrencias que de acuerdo al momento varias entre un mínimo y máximo, esto quiere decir que siempre habrá una cardinalidad mínima y cardinalidad máxima en cada relación, y esto sucede porque los datos que fluyen entre una entidad fuerte hacia una entidad débil varían de acuerdo a la ocurrencia de la relaciones. Pero en un momento el valor máximo no será varios, sino 3, ó 4 ó 5 tal vez y a eso le llamamos restricción de la cardinalidad. Supóngase que un LECTOR, va a la biblioteca a leer un LIBRO, pero decide al final que lo desea es que lo PRESTEN, pero la biblioteca tiene sus reglas y dice que solo se puede prestar 03 LIBROS a la vez; entonces al LECTOR, se le puede PRESTAR desde 01 LIBRO hasta un máximo de 03 LIBROS.
Como pueden apreciar en la figura, al LECTOR se le presta como mínimo 01 LIBRO y como máximo 03 LIBROS. Pero además tenemos que se debe registrar que LIBRO se prestan, cuanto se prestan y cuando debe devolverlo; entonces la relación se convierte en entidad y tenemos la siguiente figura.
El concepto de herencia siempre lo hemos tenido presente a través de los sucesos que no ocurren cotidianamente. Escuchamos que una persona ha heredado una fortuna que le dejo su tío abuelo, o que una persona deja en herencia a otra una propiedad, sin ser esta persona pariente o que tenga vínculo consanguíneo. En todos los casos la herencia tiene que ver con vínculos entre las personas, podemos entonces decir que si existe herencia existe un vínculo que mantiene una relación entre los objetos y esta relación necesariamente es de padre a hijo, como el caso que menciona anteriormente, pero en el siguiente en donde no son parientes, pero tiene una relación común como si fueran parientes, por lo tanto lo que tiene el objeto padre lo entrega al objeto hijo y el objeto hijo recibe del objeto padre; por lo tanto todo lo que tiene el padre es heredado por el hijo. En el mundo de las entidades y datos el concepto de herencia es que el objeto padre entrega datos al objeto hijo y el objeto hijo recibe o hereda los atributos comunes del objeto padre o objeto superior a través de una relación de herencia.
GENERALIZACIÓN Y ESPECIALIZACION
En una relación de herencia que existe entre las entidades, podemos definir un objeto de nivel superior y objeto de nivel inferior. Los objeto de nivel superior son considerados como clases y los objetos de nivel inferior son considerados como subclases y ese manera podemos tener objetos que tiene los atributos comunes a los demás objetos heredados y los objetos que no poseen atributos comunes un objeto derivado de otro objeto. Por lo tanto distinguimos dos tipos de objetos un objeto genérico y un objeto de especialización o especifico.
GENERALIZACIÓN: Pertenecen todos los objetos de nivel superior y a estos se les consideran objeto o entidades padre, superior, clase o genérico. Por lo tanto tiene los atributos comunes y serán entregados a los objeto de especialización. Una entidad son los que tiene los atributos comunes de todas las entidades, inclusive los atributos claves. En este tipo de relación los atributos son públicos y no existe cardinalidad entre las entidades.
ESPECIALIZACIÓN: Pertenecen todos los objetos de nivel inferior y a estos se les consideran objetos o entidades hijo, inferior, subclase o derivados. Por lo tanto su atributos no son comunes a los objetos genéricos, son atributos de especialización y no lo comparten con ninguna entidad superior o del mismo tipo de especialización. Estas entidades heredan o reciben los atributos comunes de las entidades de nivel superior a través de los atributos comunes, y se les llama de especialización por una especialización de la entidad genérica.
INDICADORES DE SUBTIPO/SUPERTIPO
Los tipos de objeto de subtipo/supertipo consisten en tipos de objetos de una o más categoría, conectado por una relación. La relación que mantiene los subtipos con los supertivos es por medio de una relación que no tiene nombre o no está definida, y en esta relación además el supertipo tiene una línea que contiene a una barra horizontal.
MODELO ENTIDAD RELACIÓN EXTENDIDO
Cuando dos entidades se relaciona forman un vínculo entre ellas, y este tipo de relación es una relación binaria, pero cuando tres entidades se relacionan forma un vínculo entre ellas y la relación se conoce como ternaria; en las bases de datos no puede existir este tipo de relación; por lo tanto, ya explicamos que este tipo de relación se forma por ambas entidades comparte una relación de muchos a muchos por lo tanto deberá crearse una nueva entidad. En otro caso por su naturaleza de guardar datos la relación se convierte en una entidad. Y en otro caso por la relación que deben mantener por ocurrencias en distintos tiempos y no se puede establecer una relación de relación; en ese caso el modelo entidad relación ya no puede establecer este tipo de entidad; por lo tanto tenemos el modelo entidad relación extendido (MERE), este modelo consiste en poder relacionar las tres o más entidades y poder establecer una relación de relación entre las entidades, esto lo lleva a través del concepto de agregación de entidades.
En consiste este concepto; en que una relación de entidades binarias, y en donde necesariamente debe coexistir una tercera entidad, las dos primeras son agregada a la tercera y así estas entidades forman parte de la tercera con sus demás atributos que tiene la tercera y además ya se puede establecer una relación de relación. La agregación permite combinar varios tipos de entidades relacionadas mediante un tipo de relación, para formar otra entidad de nivel superior conocida como entidad agregada, y es útil cuando esta entidad deba relacionarse con otras entidades. Esto no vamos a preciar a través de un ejemplo.
Ejemplo 1: un médico atiende a un paciente a través de una consulta.
Solución 1:
En esta solución tenemos una relación ternaria, la cual nos da un error porque toda atención de un paciente se realiza a través de una consulta programa para el paciente, si no es posible entonces el debe esperar a que el médico lo pueda atender.
Solución 2:
Para establecer la atención del paciente por medio del médico, se indica una relación de atención, pero esta atención se debe realizar a través de una consulta previamente programada.
Solución 3:
El paciente se va atender por el médico, para lo cual se programa la atención del paciente en una consulta.
RESTRICCIONES DE LA GENERALIZACIÓN Y ESPECIALIZACIÓN
Dos o más tipos de relación son exclusivos, respecto de un tipo de entidad que participa en ambos, si cada instancia del tipo de entidad sólo puede participar en uno de los tipos de relación.
Caso especial de relación entre un tipo de entidad y varios otros tipos de entidad. La jerarquía o relación que se establece entre uno y otros corresponde a la noción de “es_un” o de “es_un_tipo_de”. Estas jerarquías pueden formarse por especialización o bien por generalización.
La agrupación de instancias dentro de un tipo de entidad, que debe representarse explícitamente debido a su importancia para el diseño o aplicación.
Es la relación que se establece entre un supertipo y cada uno de sus subtipos (noción es_un o es_un_tipo_de).
Notación:
La extensión de un subtipo es un subconjunto de la extensión del supertipo.
Una instancia de subtipo también es instancia del supertipo y es la misma instancia, pero con un papel específico distinto Una instancia no puede existir sólo por ser miembro de un subtipo: también debe ser miembro del supertipo Una instancia del supertipo puede no ser miembro de ningún subtipo
En los siguientes párrafos veremos las restricciones aplicables a una especialización o a una generalización; sin embargo, por abreviar, nuestra visión se referirá solamente a la especialización en vez de a ambas técnicas.
En general podremos tener varias especializaciones definidas sobre la misma entidad o superclase. En tal caso las ocurrencias de entidad pueden pertenecer a cada una de las especializaciones. Sin embargo, una especialización puede consistir en solo una subclase. En algunas especializaciones podremos determinar exactamente que ocurrencias de entidad se convertirán en ocurrencias de cada subclase, mediante la utilización de una condición en algún atributo de la superclase. Tales subclases se llaman subclases definidas por predicado (o definidas por condición). Si todas las subclases en una especialización tienen la condición de pertenencia en el mismo atributo de la superclase, la especialización será una especialización definida por atributo y el atributo será llamado atributo de definición de la especialización. Definiremos una especialización definida por atributo en el diagrama colocando el atributo de definición cerca del arco que va desde el círculo a la superclase. Cuando no exista tal condición para determinar la pertenencia a una superclase, la subclase se llamará subclase definida por el usuario. En tales subclases, la pertenencia vendrá determinada por los usuarios de la Base de Datos cuando realicen una operación de inserción de una ocurrencia en la subclase; por tanto, elusuario especifica la pertenencia de cada ocurrencia individualmente y no mediante una condición que pueda ser evaluada automáticamente.
Se pueden aplicar dos restricciones más a la especialización. La primera es la restricción de desunión, la cual especifica que las subclases de la especialización deben estar separadas. Esto significa que una ocurrencia de la entidad puede ser miembro de como máximo una de las subclases de la especialización. Una especialización definida por atributo implica la restricción desunión, si el atributo para definir el predicado de pertenencia es simple. la figura muestra este caso, donde la d del círculo denota la desunión. También usaremos la notación d para especificar que una especialización definida por el usuario debe tener la restricción de desunión asociada, como puede verse en la especialización.
Si las subclases no son desunidas, sus conjuntos de ocurrencias pueden solaparse, esto es, la misma ocurrencia de entidad puede ser miembro de más de una subclase de la especialización. Este caso, que es el caso por defecto, se representa mediante una O en el círculo, como se muestra en el ejemplo de la figura.
La segunda restricción a la especialización se llama la restricción de totalidad, la cual puede ser parcial o total. Una restricción de especialización total especifica que cada ocurrencia de entidad de la superclase debe ser miembro de alguna subclase de la especialización. Es una especialización total; esto se representa en el diagrama ERE usando una línea doble entre el círculo y la superclase. Una línea sencilla se utiliza para representar una especialización parcial, la cual permite que una ocurrencia de entidad no pertenezca a ninguna de las subclases. Hay que tener en cuenta que las restricciones de desunión y totalidad son independientes, por tanto habrá cuatro tipos de especialización:
Desunión Total: La desunión total se refiere a subtipos o subclases que no pueden solaparse, en otras palabras estas subclases no pueden ser reemplazadas entre sí y además son todas las clases derivadas que pueden existir.
Desunión Parcial: Consiste en referirse a los subtipos o subclases que no se pueden solaparse, en otras palabras esta subclases no se pueden reemplazar entre sí y además no son todas las clases derivadas que pueden existir.
Unión Total: La Reunión total consiste cuando los subtipos o subclases de una clase o supertipo que los contienen; los subtipos se pueden solaparse entre sí, esto quiere decir que un subtipo con otro subtipo pueden reemplazarse, en otras palabras en un momento dado un subtipo 1 puede ser un subtipo 2, y en otro momento el subtipo 2 puede ser el subtipo 1. En una reunión total se presenta con todos los subtipos posibles que contiene al supertipo.
Unión Parcial: Consiste en que los subtipos de un supertipo se pueden reemplazar uno con el otro, pero esto sucede en diferentes momentos; esto se puede expresar de la siguiente manera: un subtipo 1 en un momento determinado reemplaza a un subtipo 2, y en otro momento este mismo subtipo 2 reemplaza al subtipo 1; pero en este caso los subtipo del supertipo no están completos, cabe la posibilidad que existan más subtipos que puedan pertenecer al supertipo.
Reunión Total: Cuando los subtipos no son aun subtipo de un supertipo, entonces se reúnen para formar una categorización entre ellos y así se crea un supertipo tomando las características de cada uno de ellos en forma general. Para este caso todos los subtipos forman el supertipo ni uno más.
Reunión Parcial: Como el caso de la reunión de los subtipos, en donde se categorizan los subtipos y así se crea un supertipo, pero en este caso todos los subtipo no forma parte el supertipo.
Como es lógico, las restricciones correctas vienen dadas por la naturaleza del problema real aplicado a cada especialización, sin embargo, la generalización en una superclase suele ser total, ya que la superclase se deriva de las subclases y, por tanto, contiene sólo ocurrencias de entidad que están en las subclases.
DiseÑo Top-down frente a Bottom-up
En el proceso de especialización, solemos empezar con una entidad y a continuación definimos las subclases de la entidad mediante especializaciones sucesivas; esto es, definimos repetitivamente más agrupamientos específicos a partir de la entidad. Por ejemplo, podemos especificar primero la entidad para la BD. Entonces descubriremos que se van a representar dos tipos diferentes en la BD. Para este propósito crearemos la especialización y elegiremos la restricción de solapamiento porque una entidad puede pertenecer a ambas subclases. Entonces especializaremos a la primera entidad, y luego especializamos a la segunda entidad. Finalmente especializaremos a la tercera entidad. Esta especialización sucesiva corresponde a un proceso de refinamiento conceptual top-down durante el diseño del esquema conceptual.
Hasta aquí, tendremos una jerarquía; descubriremos entonces que la tercera entidad es una subclase compartida, desde el momento en que es también una subclase de otra, llevándonos esto a una red.
Es posible llegar a la misma jerarquía o red desde otra dirección. En tal caso el proceso conlleva a la generalización en vez de especialización y corresponde a una síntesis conceptual bottom-up. En términos estructurales, las jerarquías o redes resultantes de ambos procesos puede ser idéntica; la única diferencia radica en la manera o el orden en que se especifican las clases y subclases del esquema.
En la práctica, es frecuente que no se utilice solamente especialización o solamente generalización, sino una combinación de ambos procesos. En este caso, se incorporan continuamente nuevas clases a la jerarquía o la red según se van haciendo visibles para usuarios y diseñadores.
Todas la entidades que pertenecen a una superclase o subclase, tiene una superclase única que las contiene, o se crea una superclase para que contenga esta subclases. Para establecer la subclase de la superclase, tenemos que establecer las subclases y vemos los tipos que puede ser de la superclase, a eso le llamamos categorías de la clase o superclase. En otro caso tenemos varias entidades que se convierten en clases o subclase de una superclase; para hacer esto se crea una superclase, que contenga a estas clases y sean las subclases de la superclase y esto se realiza categorizando a las clases en subclases de la superclase. Una categoría puede ser total o parcial.
DEPENDECIA FUNCIONAL
Se dice que un conjunto de atributos (A) depende funcionalmente de otro conjunto de atributos (B) si para cada valor de A hay un único valor posible para B. Representación que se denota por A → B.
Al conjunto B del que depende funcionalmente el conjunto A se le llama determinante. Al conjunto se le llama implicado.
DEPENDENCIA FUNCIONAL COMPLETA
Un conjunto de atributos (A) tiene una dependencia funcional completa sobre otro conjunto de atributo (B) si A tiene dependencia funcional de B y además no se puede obtener de B un conjunto de atributos más pequeños que consiga una dependencia funcional de A. Una dependencia funcional completa se denota como A => B. Se dice que A tiene dependencia funcional completa de B, si depende funcionalmente de B, pero no depende de ningún subconjunto del mismo, esto es:
A → B
A1 → |B
A2 → |B
Se representa A ⇒ B
A ⇒ B si y solo si NO ∃A ⊂ A /A → B
Se produce cuando A y B forma una dependencia funciona completa y además B es un único atributo. Es más compleja de explica, pero tiene también utilidad.
DEPENDENCIA FUNCIONA TRANSITIVA
Se produce cuando tenemos tres conjunto de atributos A, B y C. A depende funcionalmente de B (A→B), B depende funcionalmente de C (B → C). Además A no depende funcionalmente de C. Entonces ocurre que A produce una dependencia funcional transitiva sobre C. Esto se denota como: (A -→ C).
Para el resto de formas normales (las diseñadas por Fagin, muchos más complejos), es importante definir este tipo de dependencia, que es distinta de las funcionales. Si las funcionales eran la base de la segunda y tercera forma normal (y de la de Boyce-Codd), estas son la base de la cuarta forma normal.
Una dependencia multivaluada de una tabla con atributos A, B, C de A sobre B (es decir A->>C) ocurre cuando los posibles valores de B sobre cualquier par de valores A y C dependen solo del valor de A y son independientes de C.
Una dependencia multivaluada es una sentencia cuyo significado intuitivo es el siguiente: A cada valor de A se le asocia un conjunto de valores de B independiente del contexto (si A e B son subconjuntos de C, el contexto es Z=C - (A ∪ B)).
Es muy importante no confundir la existencia de una dependencia multivaluada con el hecho de que entre los dominios de A e B pueda establecerse una correspondencia 1:n, lo que es un error bastante frecuente.
El proceso de normalización de bases de datos consiste en aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional. Las bases de datos relacionales se normalizan para: Evitar la redundancia de los datos. Evitar problemas de actualización de los datos en las tablas. Proteger la integridad de los datos.
En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una tabla sea considerada como una relación tiene que cumplir con algunas restricciones:
Cada tabla debe tener su nombre único. No puede haber dos filas iguales. No se permiten los duplicados. Todos los datos en una columna deben ser del mismo tipo.
En la teoría de bases de datos relacionales, las formas normales (NF) proporcionan los criterios para determinar el grado de vulnerabilidad de una tabla a inconsistencias y anomalías lógicas. Mientras sea más alta la forma normal aplicable a una tabla, es menos vulnerable a inconsistencias y anomalías. Cada tabla tiene una forma normal más alta: por definición, una tabla siempre satisface los requisitos de su NF y de todas las formas normales más bajas que su NF; también por definición, una tabla no puede satisfacer los requisitos de ninguna forma normal más arriba que su NF.
Las formas normales son aplicables a tablas individuales; decir que una base de datos entera está en la forma normal n es decir que todas sus tablas están en la forma normal n.
Edgar F. Codd originalmente definió las tres primeras formas normales (1NF, 2NF, y 3NF). Estas formas normales se han resumido como requiriendo que todos los atributos no-clave sean dependientes en la clave, la clave completa, y nada excepto la clave. Las cuarta y quinta formas normales (4NF y 5NF) se ocupan específicamente de la representación de las relaciones muchos a muchos y uno muchos entre los atributos. La sexta forma normal (6NF) incorpora consideraciones relevantes a las bases de datos temporales de tiempo real.
Una tabla está en Primera Forma Normal si: Todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio son indivisibles, mínimos.
La tabla contiene una clave primaria única.
La clave primaria no contiene atributos nulos.
No debe de existir variación en el número de columnas.
Los Campos no clave deben identificarse por la clave (Dependencia Funcional)
Debe Existir una independencia del orden tanto de las filas como de las columnas, es decir, si los datos cambian de orden no deben cambiar sus significados
Una tabla no puede tener múltiples valores en cada columna. Los datos son atómicos. (Si a cada valor de A le pertenece un valor de B y viceversa)
Esta forma normal elimina los valores repetidos dentro de una BD.
Una relación está en 2FN si está en 1FN y si los atributos que no forman parte de ninguna clave dependen de forma completa de la clave principal. Es decir que no existen dependencias parciales. (Todos los atributos que no son clave principal deben depender únicamente de la clave principal), si hay atributos que depende sólo de parte de la clave, entonces esa parte de la clave y esos atributos formarán otra tabla
En otras palabras podríamos decir que la segunda forma normal está basada en el concepto de dependencia completamente funcional.
La tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia funcional transitiva entre los atributos que no son clave.
Un ejemplo de este concepto sería que, una dependencia funcional X->Y en un esquema de relación R es una dependencia transitiva si hay un conjunto de atributos Z que no es un subconjunto de alguna clave de R, donde se mantiene X->Z y Z->Y.
Formalmente, un esquema de relación R está en 3 Forma Normal Elmasri-Navathe, si para toda dependencia funcional X → A, se cumple al menos una de las siguientes condiciones:
X es superllave o clave.
A esa atributo primo de R; esto es, si es miembro de alguna clave en R.
Además el esquema debe cumplir necesariamente, con las condiciones de segunda forma normal.
La tabla se encuentra en FNBC si cada determinante, atributo que determina completamente a otro, es clave candidata. Deberá registrarse de forma anillada ante la presencia de un intervalo seguido de una formalización perpetua, es decir las variantes creadas, en una tabla no se llegaran a mostrar, si las ya planificadas, dejan de existir.
Formalmente, un esquema de relación R está en FNBC, si y sólo si, para toda dependencia funcional válida en R, se cumple que
X es superllave o clave.
De esta forma, todo esquema R que cumple FNBC, está además en 3FN; sin embargo, no todo esquema R que cumple con 3FN, está en FNBC.
Ocurre esta forma normal cuando una tabla está en forma normal de Boyce Codd y toda dependencia multivaluada es una dependencia funcional.
El teorema de Fagin indica, cuando hay tres pares de conjuntos de atributos A, B y C si ocurre A ->>B|C (B y C tienen dependencia multivaluada sobre A), entonces las tablas A, B y B, C reproducen sin perder información lo que poseía la tabla original. Este teorema marca la forma de dividir las tablas hacia una 4FN.
Una tabla también se encuentra en 4FN si, y sólo si, para cada una de sus dependencias múltiples no funcionales A->->B, siendo A una super-clave que, A es o una clave candidata o un conjunto de claves primarias.
Una tabla se encuentra en 5FN si:
La tabla está en 4FN
No existen relaciones de dependencias no triviales que no siguen los criterios de las claves. Una tabla que se encuentra en la 4FN se dice que está en la 5FN si, y sólo si, cada relación de dependencia se encuentra definida por las claves candidatas.
La forma normal de dominio/clave (DKNF) es una forma normal usada en normalización de bases de datos que requiere que la base de datos contenga restricciones de dominios y de claves.
Una restricción del dominio especifica los valores permitidos para un atributo dado, mientras que una restricción clave especifica los atributos que identifican únicamente una fila en una tabla dada.
Este es el dilema de las Bases de datos y es alcanzado cuando cada restricción en la relación es una consecuencia lógica de la definición de claves y dominios, y, haciendo cumplir las restricciones y condiciones de la clave y del dominio, causa que sean satisfechas todas las restricciones. Así, esto evita todas las anomalías no temporales.
Es mucho más fácil construir una base de datos en forma normal de dominio/clave que convertir pequeñas bases de datos que puedan contener numerosas anomalías. Sin embargo, construir con éxito una base de datos en forma normal de dominio/clave sigue siendo una tarea difícil, incluso para programadores experimentados de bases de datos. Así, mientras que la forma normal de dominio/clave elimina los problemas encontrados en la mayoría de las bases de datos, tiende para ser la forma normal más costosa de alcanzar. Sin embargo, el no poder alcanzar la forma normal de dominio/clave puede llevar costos ocultos a largo plazo, debido a anomalías que aparecen con el tiempo en las bases de datos que solamente se adhieren a formas normales más bajas.
Una de las herramientas del modelado de datos más importante es el diccionario de datos, aunque no tiene presencia y el atractivo gráfico de los diagramas entidad relación. Sin los diccionarios de datos, el modelado de los requerimientos del usuario no puede considerarse completo.
El diccionario de datos es un listado organizado de todos los datos pertenecientes al modelo de datos, con definiciones precisas y rigurosas para que tanto el usuario como el analista tengan un entendimiento común de todas las entradas, salidas, componentes de almacenes y cálculos intermedios.
El diccionario de datos contiene las características lógicas y puntuales de los datos que se van a utilizar en el sistema que se programa, incluyendo nombre, descripción, alias, contenido y organización.
Identifica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a la información, se desarrolla durante el análisis de flujo de datos y auxilia a los analistas que participan en la determinación de los requerimientos del sistema, su contenido también se emplea durante el diseño.
Estos diccionarios se desarrollan durante el análisis de flujo de datos y ayuda a los analistas que participan en la determinación de los requerimientos del sistema, su contenido también se emplea durante el diseño del proyecto.
NOTACIÓN DEL DICCIONARIO DE DATOS
Existen muchos esquemas de notación comunes utilizados por el modelador de datos o analista de sistema. El que se muestra a continuación es de los más comunes u utiliza varios símbolos:
= está compuesto por
+ además de
( ) opcional (puede estar presenta o ausente)
{ } agrupación
* iteracción
[ ] seleccionar una de varias alternativas
** comentario
@ identificador (atributo clave) para un contenedor
| separar opciones alternativas en el diseño
Ejemplos
Estructura nombre = título de cortesía + nombre + (segundo nombre) + apellido
título de cortesía = [Sr. | Srta. | Sra. | Dr. | Prof.]
nombre = {carácter válido}
segundo nombre = {carácter válido}
apellido = {carácter válido}
carácter válido = [ A-Z | a-z | ‘ | - ]
domicilio del cliente = (domicilio de envío) + (domicilio de facturación)
domicilio del cliente = [domicilio de envío | domicilio de facturación | domicilio de envío + (domicilio de facturación)]
domicilio del cliente = domicilio de envío + (domicilio de facturación)
solicitud = nombre del cliente + domicilio de envío + 1{artículo}*10
sexo = [Femenino | Masculino]
tipo de cliente = [Gobierno | Industria | Universidad | Otro]
DICCIONARIO DE DATOS PARTE 1 REVISAR LA DOCUMENTACION DEL DATO
Las organizaciones utilizan gran cantidad de documentos para sus operaciones diarias de procesamiento de la información, estos datos son ingresados a los sistemas de sistemas de información y luego son procesados para todas las áreas de la organización. Pero la organización no solo tiene un sistema de información, pues tiene varios sistemas y varias bases de datos los cuales se distribuyen en toda la organización. Por lo tanto la documentación debe ser la que nos permita obtener los datos que se serán necesarios para realizar el modelamiento de los datos y así construir la base de datos. En esta parte vamos a diseñar el modelo de datos para luego construir las tablas de la base de datos, para lo cual tomaremos un documento y extraeremos los datos que tiene.
Tenemos un documento de venta de la farmacia “Los Ángeles”, el cual detalla la venta del día, en donde se puede apreciar los datos del cliente, los datos de venta, los datos del producto comprado y los datos del obsequio recibido. Los primero que vamos hacer es descartar los datos calculables, estos se pueden obtener de otros datos en operaciones de cálculo y los siguientes descuento y total, porque estos valores se pueden calcular; estos datos no irán en el modelo de datos. El monto que aparece en detalle es un atributo derivado, por el valor se obtiene de los datos cantidad y precio, luego el atributo descuento es almacenado, porque de allí se obtendrá el subtotal del medicamento comprado. Entonces la entidad a obtener es la siguiente.
Venta=@numerodeventa+fecha+{@cliente+documento[dni|ruc]+numero+direccion+ urbanizacion+distrito+telefono1+telefono2+celular+nextel}+{cantidad+medicamento +descripcion+tipo+precio+monto+descuento+subtotal}*n+{cantidad+marca+descripcion+precio +monto+descuento+subtotal}+monto.
Como se puede apreciar el documento venta está compuesto de cuatro partes: la parte de la venta, la parte del cliente, la parte del detalle de venta y la parte del obsequio y no olvidar la parte de los totales y del impuesto.
DICCIONARIO DE DATOS PARTE 2 NORMALIZAR LOS DATOS DEL DOCUMENTO
El diccionario de datos es muy útil, porque de esta manera podemos definir la estructura de una tabla y su contenido; que datos serán tendrá y como estos datos serán visibles dentro de una vista o a ser presentados por los gestores de sistemas de información.
En la parte dos, a través de las formas normales se subdividirá los documentos de la organización en varias partes y de esa forma tendremos el modelo de datos que luego se convertirá en tablas de una base de datos y de esa forma se organizará los datos y podemos tener acceso de una forma conveniente y poder solicitar la información que se requiera.
Normalizaremos los datos del documento de venta de la farmacia “Los Ángeles”, que está en el apartado anterior teniendo la siguiente información obtenida del documento de la farmacia:
Venta=@numerodeventa+fecha+{@cliente+documento[dni|ruc]+numero+direccion+ urbanizacion+distrito+telefono1+telefono2+celular+nextel}+{cantidad+medicamento +descripcion+tipo+precio+monto+descuento+subtotal}*n+{cantidad+marca+descripcion+precio +monto+descuento+subtotal}+monto.
Lo primero que debemos establecer cuáles son las posibles claves candidatas que muestra el documento; podemos observar de acuerdo al diccionario de datos las claves candidatas están identificada por el símbolo @ y estas son @numerodeventa, @cliente y posiblemente el código del medicamento que no aparece en el documento, pero eso no significa que no tuviera un código el medicamento; otra clave sería el código del obsequio, que tampoco se observa en el documento, pero todo obsequio debe tener un código, ya que también es un producto que la farmacia comercializa. Bien ya tenemos las posibles claves candidatas que este documento tiene, ahora vamos a la normalización. La normalización podemos hacerlo por las tres formas normales y por la forma normal de Boyce-Codd.
Lo haremos por las tres formas normales inicial mente y luego por la forma normal de Boyce-Codd. En las formas normales primero empezaremos por la primera forma normal; que dice, que los datos dependen de una clave y estos datos no se podrán dividir son atómicamente imposible del dominio, para ello vamos a establecer esa dependencia y lo haremos a través de la dependencias funcionales; que también dice; que un determinante depende de otro, siempre y cuando este determinante necesite al otro para su existencia. Por lo tanto tendríamos las relaciones siguientes:
R1=@numerodeventa+fecha+{@cliente+documento[dni|ruc]+numero+direccion+urbanisacion+ distrito+telefono1+ telefono2+celular+nextel}+monto
R2=@numerodeventa+{@codigo+cantidad+medicamento+descripcion+tipo+precio+monto+ descuento+subtotal}*n+monto
R3=@numerodeventa+{@codigo+cantidad+marca+descripcion+precio+monto+descuento+ subtotal}
Bueno ya tenemos las tres primeras relaciones obtenidas del documento de venta de la farmacia; y estas relaciones son las siguientes: R1, si lee los datos que contiene esta relación observaremos que tenemos datos del cliente y datos de venta, por lo tanto algunos atributos depende de la clave principal que es el atributo @numerodeventa, mientras que otros atributos dependen del atributo clave @cliente. En la segunda relación R2, algunos atributos depende de la clave principal @numerodeventa y otros no, depende del atributo clave @codigo del medicamento comprado por parte del cliente. En la tercera relación R3, algunos atributos depende de la clave principal @numerodeventa y otros no, depende del atributo clave @codigo que corresponde al obsequio que recibe el cliente por la compra según criterio de adquisición.
Se puede concluir que en las relaciones R1, se tiene el documento de venta con los datos del cliente que adquiere algún producto a través de la compra; mientras que en la relación R2 se tiene la relación del documento de venta con los medicamentos que el cliente ha comprado, y en la relación R3, se pude observar la relación que tiene el documento de venta con el obsequio recibido el cliente por parte de la organización por su compra especial según criterio de compra que ha establecido la organización.
Además podemos observar que ninguna de las relaciones (R1, R2, R3) está normalizada ni siquiera en la primera forma normal, para lo cual empezaremos la normalización
R1=@numerodeventa+fecha+{@cliente+documento[dni|ruc]+numero+direccion+urbanizacion+ distrito+telefono1+telefono2+celular+nextel}+monto
Para normalizar descompondremos la relación R1 en las siguientes relaciones:
R11=@numerodeventa+fecha+@cliente
R12=@numerodeventa+{@cliente+documento[dni|ruc]+numero+direccion+urbanizacion+ distrito+telefono1+telefono2+celular+nextel}
En la primera relación R11 todos los atributos no claves depende de la clave, para mantener la relación, así tenemos que el atributo fecha depende funcionalmente de @numerodeventa y @cliente depende también de @numerodeventa. Por lo tanto podemos decir que R11 está en primera forma normal. Mientras que R12 no lo está, por existir dependencias parciales.
R2=@numerodeventa+{@codigo+cantidad+medicamento+descripcion+tipo+precio+monto+ descuento+subtotal}*n
Para normalizar descompondremos la relación R2 en las siguientes relaciones:
R21=@numerodeventa+@codigo+cantidad+monto1+descuento+subtotal
R22=@numerodeventa+@codigo+medicamento+descripcion+tipo+precio
En la relación R21 todos los atributos no claves depende de la clave, para mantener la relación, así tenemos que el atributo @codigo depende funcionalmente de @numerodeventa, cantidad también depende del @numerodeventa, monto1 depende funcionalmente de @numerodeventa, descuento depende funcionalmente de @numerodeventa y subtotal depende funcionalmente de @numerodeventa. Mientras que en la R22 no todos los atributos depende de la clave @numerodeventa, porque existe dependencias parciales.
R3=@numerodeventa+{@codigo+cantidad+marca+descripcion+precio+monto+descuento+ subtotal}
Para normalizar descompondremos la relación R3 en las siguientes relaciones:
R31=@numerodeventa+@codigo+cantidad+monto+descuento+subtotal
R32=@numreodeventa+@codigo+marca+descripcion+precio
En la relación R31 todos los atributos no claves depende de la clave, para mantener la relación, así tenemos que el atributo @codigo depende funcionalmente de @numerodeventa, la cantidad comprada depende del atributo @numerodeventa, el monto que se obtiene de la operación cantidad por precio depende del atributo @numerodeventa, el descuento que se realiza al producto depende del atributo @numerodeventa, subtotal es el monto parcial de la compra del producto también depende del atributo @numerodeventa. Por lo tanto esta relación si esta en primera forma normal.
En R32 tenemos dependencias parciales por lo tanto esta relación no está en primera forma normal, ya que los atributos no claves como marca, descripción y precio tiene una dependencia con el atributo @codigo; solo existe una dependencia con el atributo clave @numerodeventa el atributo @codigo.
En primera forma normal están:
R11=@numerodeventa+fecha+@cliente
R21=@numerodeventa+@codigo+cantidad+monto1+descuento+subtotal
R31=@numerodeventa+@codigo+cantidad+monto+descuento+subtotal
R12=@numerodeventa+{@cliente+documento[dni|ruc]+numero+direccion+urbanizacion+ distrito+telefono1+telefono2+celular+nextel}
La siguiente relación no está en primera forma normal, porque tenemos dependencias parciales, no todos los atributos no claves depende de la clave, por lo tanto esta relación se descompondrá de la siguiente manera:
R121=@numerodeventa+@cliente+documento[dni|ruc]+numero+direccion+urbanizacion+ distrito+telefono1+telefono2+celular+nextel
R122=@numerodeventa+@cliente+a
En donde la “a” representa todos los atributos del cliente, pero la relación R11 tenemos el atributo @cliente que permite establecer una relación entre el cliente y la venta que se le hace a este, por lo tanto la relación R122 se descarte porque es igual a la relación R11 más el atributo fecha. Pero en la relación R121, tenemos existe una dependencia parcial entre el atributo clave @numerodeventa y el atributo @cliente; pero tiene una dependencia con los demás atributos de la relación por lo tanto tendremos la siguiente relación derivada de R121, por lo tanto se considerara la relación R121.
R121=@numerodeventa+@cliente+documento[dni|ruc]+numero+direccion+ urbanizacion+distrito+telefono1+telefono2+celular+nextel
R22=@numerodeventa+@codigo+medicamento+descripcion+tipo+precio
La siguiente relación no está en primera forma normal, porque existe dependencias parciales entre los atributos, esto se explica que los atributos medicamente, descripción, tipo y precio tiene una dependencia con el atributo @codigo, pero no así con el atributo clave @numerodeventa, por lo tanto tenemos que normalizar esta relación y por lo tanto estaríamos pasando a la segunda forma normal. La relación R22 se descompondrá de la siguiente manera:
R221=@numerodeventa+@codigo+medicamento+descripcion+tipo+precio
R222=@numerodeventa+@codigo+b
Ahora tendríamos dos relaciones en donde la relación R221 estaría en primera forma normal y además en segunda forma normal porque no existirían dependencias parciales y además “b” representa los demás datos de la entidad medicamento para mantener la relación original de R22. Pero R222 estaría representado por la relación R21 en donde del atributo @codigo tenemos los demás atributos del detalle de la venta de medicamentos. Y por tanto la relación R222 sería descartada por igual a la relación R21; solo consideramos a la relación R221.
R221=@numerodeventa+@codigo+medicamento+descripcion+tipo+precio
R32=@numreodeventa+@codigo+marca+descripcion+precio
La relación R32 no está en primera forma normal porque existen dependencias parciales, el único atributo que depende del atributo clave es el atributo @codigo y los demás atributos no depende de la clave. Por lo tanto esta relación se descompondrá de la siguiente manera:
R321=@numreodeventa+@codigo+marca+descripcion+precio
R322=@numreodeventa+@codigo+c
En donde “c” representa a todos los atributos de la entidad obsequio, entonces en esta relación los atributos no claves como @codigo si tiene una dependencia con el atributo clave @numerodeventa y como el atributo @codigo identifica al obsequio y no la “c”, entonces estaría en primera forma normal y en segunda forma normal, además cabe mencionar que la relación R322 es igual a la relación R31 que incluye además del atributo @codigo los demás atributos del detalle de venta como son: cantidad, monto, descuento, subtotal; por lo tanto esta relación se descarta por ser igual a la relación R31.
Entonces solo nos que la relación:
R321=@numreodeventa+@codigo+marca+descripcion+precio
En primera forma normal están:
R11=@numerodeventa+fecha+@cliente
R21=@numerodeventa+@codigo+cantidad+monto1+descuento+subtotal
R31=@numerodeventa+@codigo+cantidad+monto+descuento+subtotal
En segunda forma normal están:
R11=@numerodeventa+fecha+@cliente
R21=@numerodeventa+@codigo+cantidad+monto1+descuento+subtotal
R31=@numerodeventa+@codigo+cantidad+monto+descuento+subtotal
R12=@numerodeventa+{@cliente+documento[dni|ruc]+numero+direccion+urbanizacion+ distrito+telefono1+telefono2+celular+nextel} se descompone en:
R121=@numerodeventa+@cliente+documento[dni|ruc]+numero+direccion+urbanizacion+ distrito+telefono1+telefono2+celular+nextel
R122=@numerodeventa+@cliente+a se descarta por ser igual a R11
R121=@numerodeventa+@cliente+documento[dni|ruc]+numero+direccion+urbanizacion+ distrito+telefono1+telefono2+celular+nextel
R22=@numerodeventa+@codigo+medicamento+descripcion+tipo+precio
se descompone en:
R221=@numerodeventa+@codigo+medicamento+descripcion+tipo+precio
R222=@numerodeventa+@codigo+b se descarte por ser igual a R21
R221=@numerodeventa+@codigo+medicamento+descripcion+tipo+precio
R32=@numreodeventa+@codigo+marca+descripcion+precio se descompone en:
R321=@numreodeventa+@codigo+marca+descripcion+precio
R322=@numreodeventa+@codigo+c se descarta por ser igual a R31
R321=@numreodeventa+@codigo+marca+descripcion+precio
Las relaciones que no están normalizadas pasarán a la tercera forma normal y estas son las siguientes:
R121=@numerodeventa+@cliente+documento[dni|ruc]+numero+direccion+urbanizacion+ distrito+telefono1+telefono2+celular+nextel
R221=@numerodeventa+@codigo+medicamento+descripcion+tipo+precio
R321=@numreodeventa+@codigo+marca+descripcion+precio
Estas relaciones solo uno de los atributos mantiene una dependencia con el atributo clave @numerodeventa, como podemos apreciar en el enunciado de las relaciones, y estos atributos son los siguientes: @cliente, @codigo, es el identificador de la entidad medicamento, y el atributo @codigo, es el identificado de la entidad obsequio. Los demás atributos no tiene dependencia con el atributo clave @numerodeventa, por lo tanto mantenemos una dependencia parcial como se presenta en la segunda forma normal. Como estamos en la tercera forma normal, debemos determinar que no exista en la relaciones dependencia transitiva entre los atributos de las entidades y además que no existe entre los atributos no claves dependencias entre sí, eso quiere decir que los atributos no claves deben ser totalmente independientes, para lo cual vamos a resolver las últimas relaciones que nos queda del caso venta de la farmacia “Los Ángeles”.
R121=@numerodeventa+@cliente+documento[dni|ruc]+numero+direccion+urbanizacion+ distrito+telefono1+telefono2+celular+nextel
En esta relación tenemos que los atributos documento, numero, dirección, urbanización, distrito, telefono1, telefono2, celular y nextel son atributos de la entidad cliente y por lo tanto no mantiene una relación de dependencia con el atributo clave @numerodeventa. Por lo tanto descompondremos esta relación en:
R1211=@cliente+documento[dni|ruc]+numero+direccion+urbanisacion+distrito+telefono1+ telefono2+celular+nextel
R1212=@numerodeventa+a
En la relación R1212 tenemos el atributo clave @numerodeventa y el atributo “a” que representa a los datos del cliente, y como uno de los atributo de la entidad cliente es el atributo clave @cliente y además lo identifica, tenemos que se mantiene una relación entre las entidades, y además observamos que esta relación se parece a la relación R11 y como son iguales la descartamos. En la relación R1212 tenemos los atributos de la entidad cliente que son reemplazados por “a”, como se ve en la relación R1212, pero si descomponemos la relación en dos, tendríamos por un lado tendríamos a @numerodeventa y por otro lado a “a” que representa a los datos de cliente y por atributo compuesto podemos decir, que el atributo compuesto está formado de varios atributos simples en este caso por el atributo @numerodeventa y el atributo “a” que representa cliente, en conclusión tendremos los siguientes atributos:
@numerodeventa
a=R1211 en donde tenemos:
R1211=@cliente+documento[dni|ruc]+numero+direccion+urbanisacion+distrito+telefono1+ telefono2+celular+nextel
En esta relación tenemos que todos los atributos no clave depende del atributo clave @cliente, viene hacer el atributo identificador de la entidad cliente y todos los demás atributos pertenece e identifica a la entidad cliente. Entonces la relación R1211 está en primera forma normal y al excluir todas las dependencias parciales también está en segunda forma normal y como no existen dependencias transitivas y los atributos no claves son independientes entre sí está en tercera forma normal.
R221=@numerodeventa+@codigo+medicamento+descripcion+tipo+precio
En esta relación tenemos que el único atributo que tiene una dependencia con el atributo clave @numerodeventa es el atributo @codigo, los demás atributos no tiene una dependencia con el atributo clave, más bien tiene una dependencia parcial, esto quiere decir que existen dependencias transitivas por lo tanto habrá que descomponerlo de esta manera:
R2211=@codigo+medicamento+descripcion+tipo+precio
R2212=@numerodeventa+a
En la relación R2212 tenemos los siguientes atributos; el atributo clave @numerodeventa y el atributo “a” que representa a los atributos de la entidad medicamento, y como uno de los atributos de la entidad medicamento es @codigo, por lo tanto mantiene una relación entre las entidades, y además observamos que esta relación se parece a la relación R21 incluyendo los atributos de detalle, por lo tanto se descarta. Entonces por una propiedad de los atributos compuesto, podemos separar la relación en dos, ya que los atributos compuestos están formados de varios atributos simples y esta relación de atributo compuesto está formada por el atributo simple @numerodeventa y el atributo “a”, el cual como ya sabemos reemplaza a los atributos de la entidad medicamento. Entonces tendríamos la descomposición de la siguiente manera:
@numerodeventa
a=R2211 en donde tenemos:
R2211=@codigo+medicamento+descripcion+tipo+precio
En esta relación tenemos que todos los atributos no clave depende del atributo clave @codigo, viene hacer el atributo identificador de la entidad medicamento y todos los demás atributos pertenece e identifica a la entidad medicamento. Entonces la relación R1211 está en primera forma normal y al excluir todas las dependencias parciales también está en segunda forma normal y como no existen dependencias transitivas y los atributos no claves son independientes entre sí está en tercera forma normal.
R321=@numreodeventa+@codigo+marca+descripcion+precio
En esta relación tenemos que el único atributo que tiene una dependencia con el atributo clave @numerodeventa es el atributo @codigo, los demás atributos no tiene una dependencia con el atributo clave, más bien tiene una dependencia parcial, esto quiere decir que existen dependencias transitivas por lo tanto habrá que descomponerlo de esta manera:
R3211=@codigo+marca+descripcion+precio
R3212=@numreodeventa+a
En la relación R3211 tenemos los siguientes atributos; el atributo clave @numerodeventa y el atributo “a” que representa a los atributos de la entidad obsequio, y como uno de los atributos de la entidad obsequio es @codigo, por lo tanto mantiene una relación entre las entidades, y además observamos que esta relación se parece a la relación R31 incluyendo los atributos de detalle, por lo tanto se descarta. Entonces por una propiedad de los atributos compuesto, podemos separar la relación en dos, ya que los atributos compuestos están formados de varios atributos simples y esta relación de atributo compuesto está formada por el atributo simple @numerodeventa y el atributo “a”, el cual como ya sabemos reemplaza a los atributos de la entidad obsequio. Entonces tendríamos la descomposición de la siguiente manera:
@numerodeventa
a=R3211 en donde tenemos:
R3211=@codigo+marca+descripcion+precio
En esta relación tenemos que todos los atributos no clave depende del atributo clave @codigo, viene hacer el atributo identificador de la entidad obsequio y todos los demás atributos pertenece e identifica a la entidad obsequio. Entonces la relación R3211 está en primera forma normal y al excluir todas las dependencias parciales también está en segunda forma normal y como no existen dependencias transitivas y los atributos no claves son independientes entre sí está en tercera forma normal.
En primera forma normal están:
R11=@numerodeventa+fecha+@cliente
R21=@numerodeventa+@codigo+cantidad+monto1+descuento+subtotal
R31=@numerodeventa+@codigo+cantidad+monto+descuento+subtotal
En segunda forma normal están:
R11=@numerodeventa+fecha+@cliente
R21=@numerodeventa+@codigo+cantidad+monto1+descuento+subtotal
R31=@numerodeventa+@codigo+cantidad+monto+descuento+subtotal
R12=@numerodeventa+{@cliente+documento[dni|ruc]+numero+direccion+urbanizacion+ distrito+telefono1+telefono2+celular+nextel} se descompone en:
R121=@numerodeventa+@cliente+documento[dni|ruc]+numero+direccion+urbanizacion+ distrito+telefono1+telefono2+celular+nextel
R122=@numerodeventa+@cliente+a se descarta por ser igual a R11
R121=@numerodeventa+@cliente+documento[dni|ruc]+numero+direccion+urbanizacion+ distrito+telefono1+telefono2+celular+nextel
R22=@numerodeventa+@codigo+medicamento+descripcion+tipo+precio
se descompone en:
R221=@numerodeventa+@codigo+medicamento+descripcion+tipo+precio
R222=@numerodeventa+@codigo+b se descarte por ser igual a R21
R221=@numerodeventa+@codigo+medicamento+descripcion+tipo+precio
R32=@numreodeventa+@codigo+marca+descripcion+precio se descompone en:
R321=@numreodeventa+@codigo+marca+descripcion+precio
R322=@numreodeventa+@codigo+c se descarta por ser igual a R31
R321=@numreodeventa+@codigo+marca+descripcion+precio
En tercera forma normal están:
R11=@numerodeventa+fecha+@cliente
R21=@numerodeventa+@codigo+cantidad+monto1+descuento+subtotal
R31=@numerodeventa+@codigo+cantidad+monto+descuento+subtotal
R121=@numerodeventa+@cliente+documento[dni|ruc]+numero+direccion+urbanizacion+ distrito+telefono1+telefono2+celular+nextel se descompone en:
R1211=@cliente+documento[dni|ruc]+numero+direccion+urbanisacion+distrito+telefono1+ telefono2+celular+nextel
R1212=@numerodeventa+a se descarta por ser igual a R11
R221=@numerodeventa+@codigo+medicamento+descripcion+tipo+precio se descompone en:
R2211=@codigo+medicamento+descripcion+tipo+precio
R2212=@numerodeventa+a se descarta por ser igual a R21
R321=@numreodeventa+@codigo+marca+descripcion+precio se descompone en:
R3211=@codigo+marca+descripcion+precio
R3212=@numreodeventa+a se descarta por ser igual a R31
Finalmente tenemos las siguientes relaciones que viene hacer las tablas de la base de datos:
R11=@numerodeventa+fecha+@cliente
R21=@numerodeventa+@codigo+cantidad+monto1+descuento+subtotal
R31=@numerodeventa+@codigo+cantidad+monto+descuento+subtotal
R1211=@cliente+documento[dni|ruc]+numero+direccion+urbanisacion+distrito+telefono1+ telefono2+celular+nextel
R2211=@codigo+medicamento+descripcion+tipo+precio
R3211=@codigo+marca+descripcion+precio
En donde:
R11 viene hacer venta
R21 viene hacer detalle de venta
R31 viene hacer detalle de regalo
R1211 viene hacer cliente
R2211 viene hacer medicamento
R3211 viene hacer producto que se regala
DICCIONARIO DE DATOS PARTE 3 DEFINICION DE LAS TABLAS
Es esta parte del diccionario de datos se describe las tablas que tendrá la base de datos, como también el tipo de tabla o archivo que estará en la base de datos, así también los campos o atributos de la tabla. La definición que se considera en el diccionario de datos es los tipos de datos que cada tabla contendrá, además el rango de valores que puede asumir algún tipo de atributo o campo, el atributo clave y los atributos candidatos de claves, valores permitidos en los datos, los valores nulos, valor por defecto a ser presentado, etc.
A continuación se presentarán las definiciones de las tablas que se obtuvieron de la normalización de los datos del documento de venta de la farmacia “Los Ángeles”, vernos como se define las tablas y los campos respectivos de estas.
