Академический Документы
Профессиональный Документы
Культура Документы
Este artculo o seccin necesita referencias que aparezcan en una publicacin acreditada, como revistas especializadas, monografas, prensa diaria o pginas de Internet fidedignas.
Puedes aadirlas as o avisar al autor principal del artculo en su pgina de discusin pegando: {{subst:Aviso referencias|Modelo entidad-relacin}}
~~~~
Un diagrama o modelo entidad-relacin (a veces denominado por sus siglas en ingls, E-R "Entity relationship", o del espaol DER "Diagrama de Entidad Relacin") es una herramienta para el modelado de datosque permite representar las entidades relevantes de unsistema de informacin as como sus interrelaciones y propiedades.
ndice
[ocultar]
o o o o
3 Restricciones
o o
o o o
6 Diagramas extendidos
o o o o o
6.1 Entidades fuertes y dbiles 6.2 Cardinalidad de las relaciones 6.3 Atributos en relaciones 6.4 Herencia 6.5 Agregacin
Transformacin de relaciones mltiples en binarias. Normalizacin de una base de datos de relaciones (algunas relaciones pueden transformarse en atributos y viceversa).
Una persona. (Se diferencia de cualquier otra persona, incluso siendo gemelos).
Un automvil. (Aunque sean de la misma marca, el mismo modelo,..., tendrn atributos diferentes, por ejemplo, el nmero de chasis).
Una entidad puede ser un objeto con existencia fsica como: una persona, un animal, una casa, etc. (entidad concreta); o un objeto con existencia conceptual como: un puesto de trabajo, una asignatura de clases, un nombre,etc. (entidad abstracta). Una entidad est descrita y se representa por sus caractersticas o atributos. Por ejemplo, la entidad Persona las caractersticas: Nombre, Apellido, Gnero, Estatura, Peso, Fecha de nacimiento.
(1, Sofa, 38 aos, 2) (2, Josefa, 19 aos, 5) (3, Carlos, 20 aos, 2) ...
Cada una de las entidades pertenecientes a este conjunto se diferencia de las dems por el valor de sus atributos. Ntese que dos o ms entidades diferentes pueden tener los mismos valores para algunos de sus atributos, pero nunca para todos. En particular, los atributos identificativos 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 nmero de id. Para cada atributo, existe un dominio del mismo, este hace referencia al tipo de datos que ser almacenado o a restricciones en los valores que el atributo puede tomar (cadenas de caracteres, nmeros, solo dos letras, solo nmeros mayores que cero, solo nmeros enteros...).
Cuando algn atributo correspondiente a una entidad no tiene un valor determinado, recibe el valor nulo, bien sea porque no se conoce, porque no existe o porque no se sabe nada al respecto del mismo.
Ejemplo: Si tenemos dos entidades, "CLIENTE" y "HABITACION", podemos entender la relacin entre ambas al tomar un caso concreto (ocurrencia) de cada una de ellas. Entonces, podriamos tener la ocurrencia "Habitacin 502", de la entidad "HABITACION" y la ocurrencia "Henry Jonshon Mcfly Bogard", de la entidad "CLIENTE", entre las que es posible relacionar que la habitacin 502 se encuentra ocupada por el husped de nombre Henry.
Una relacin tiene sentido al expresar las entidades que relaciona. En el ejemplo anterior, podemos decir que un husped (entidad), se aloja (relacin) en una habitacin (entidad).
Dado un conjunto de relaciones en el que participan dos o ms conjuntos de entidades, la correspondencia de cardinalidad indica el nmero de entidades con las que puede estar relacionada una entidad dada. Dado un conjunto de relaciones binarias y los conjuntos de entidades A y B, la correspondencia de cardinalidades puede ser:
Uno a Uno: (1:1) Una entidad de A se relaciona nicamente con una entidad en B y viceversa (ejemplo relacin vehculo - matrcula: cada vehculo tiene una nica matrcula, y cada matrcula est asociada a un nico vehculo).
Uno a varios: (1:N)Una entidad en A se relaciona con cero o muchas entidades en B. Pero una entidad en B se relaciona con una nica entidad en A (ejemplo vendedor - ventas).
Varios a Uno: (N:1)Una entidad en A se relaciona exclusivamente con una entidad en B. Pero una entidad en B se puede relacionar con 0 o muchas entidades en A (ejemplo empleado-centro de trabajo).
Varios a Varios: (N:M)Una entidad en A se puede relacionar con 0 o muchas entidades en B y viceversa (ejemplo asociaciones- ciudadanos, donde muchos ciudadanos pueden pertenecer a una misma asociacin, y cada ciudadano puede pertenecer a muchas asociaciones distintas).
Total: Cuando cada entidad en A participa en al menos una relacin de R. Parcial: Cuando al menos una entidad en A NO participa en alguna relacin de R.
Superclave: Es un subconjunto de atributos que permite distinguir unvocamente cada una de las entidades de un conjunto de entidades. Si se aade un atributo al anterior subconjunto, el resultado seguir siendo una superclave.
Clave candidata: Dada una superclave, si sta deja de serlo quitando nicamente uno de los atributos que la componen, entonces sta es una clave candidata.
Clave primaria: Es una clave candidata, elegida por el diseador de la base de datos, para identificar unvocamente las entidades en un conjunto de entidades.
Los valores de los atributos de una clave, no pueden ser todos iguales para dos o ms instancias. Para poder distinguir unvocamente las relaciones en un conjunto de relaciones R, se deben considerar dos casos:
R NO tiene atributos asociados: En este caso, se usa como clave primaria de R la unin de las claves primarias de todos los conjuntos de entidades participantes.
R tiene atributos asociados: En este caso, se usa como clave primaria de R la unin de los atributos asociados y las claves primarias de todos los conjuntos de entidades participantes.
Si el conjunto de relaciones, R, sobre las que se pretende determinar la clave primaria est compuesto de relaciones binarias, con los conjuntos de entidades participantes A y B, se consideran los siguientes casos, segn sus cardinalidades:
R es de muchos a uno de A a B entonces slo se toma la clave primaria de A, como clave primaria de R.
R es de uno a muchos de A a B entonces se toma slo la clave primaria de B, como clave primaria de R.
R es de uno a uno de A a B entonces se toma cualquiera de las dos claves primarias, como clave primaria de R.
R es de muchos a muchos de A a B entonces se toma la unin de los atributos que conforman las claves primarias de A y de B, como clave primaria de R.
DER extendido
Los diagramas Entidad-Relacin no cumplen su propsito con eficacia debido a que tienen limitaciones semnticas. Por ese motivo se suelen utilizar losdiagramas Entidad-Relacin extendidos que incorporan algunos elementos ms al lenguaje:
Cuando una entidad participa en una relacin puede adquirir un papel fuerte odbil. Una entidad dbil es aquella que no puede existir sin participar en la relacin; es decir, aquella que no puede ser unvocamente identificada solamente por sus atributos. Una entidad fuerte (tambin conocida como entidad regular) es aquella que s puede ser identificada unvocamente. En los casos en que se requiera, se puede dar que una entidad fuerte "preste" algunos de sus atributos a una entidad dbil para que esta ltima se pueda identificar. Las entidades dbiles se representan- mediante un doble rectngulo; es decir, un rectngulo con doble lnea. Se puede hablar de la existencia de 2 tipos de dependencias en las entidades dbiles:
Las ocurrencias de la entidad dbil pueden identificarse mediante un atributo identificador clave sin necesidad de identificar la entidad fuerte relacionada.
La entidad dbil no puede ser identificada sin la entidad fuerte relacionada. (Ejemplo: si tenemos una entidad LIBRO y otra relacionada EDICIN, para identificar una edicin necesitamos conocer el identificador del libro).
"0" si cada instancia de la entidad no est obligada a participar en la relacin. "1" si toda instancia de la entidad est obligada a participar en la relacin y, adems, solamente participa una vez.
"N" , "M", "*" si cada instancia de la entidad no est obligada a participar en la relacin y puede hacerlo cualquier nmero de veces.
Cada esposo (entidad) est casado (relacin) con una nica esposa (entidad) y viceversa. Es una relacin 1:1.
Una factura (entidad) se emite (relacin) a una persona (entidad) y slo una, pero una persona puede tener varias facturas emitidas a su nombre. Todas las facturas se emiten a nombre de alguien. Es una relacin 1:N.
Un cliente (entidad) puede comprar (relacin) varios servicios (entidad) y un servicio puede ser comprado por varios clientes distintos. Es una relacin N:M.
Ejemplo agregacin
Es una abstraccin a travs de la cual las relaciones se tratan como entidades de un nivel ms alto. Se utiliza para expresar relaciones entre relaciones o entre entidades y relaciones. Se representa englobando la relacin abstrada y las entidades que participan en ella en un rectngulo. En la figura se
muestra un ejemplo de agregacin en el que se representa la situacin en la que un profesor, cuando est impartiendo una clase, puede poner una incidencia ocurrida a lo largo de sta (se fue la luz, falta la configuracin de un determinado software, etc.).
Atributos y Llaves
Los atributos, tanto de entidades como de relaciones, toman sus valores posibles de un conjunto llamado dominio. El dominio es, entonces, el conjunto de valores posibles que puede tomar un atributo dado de un conjunto de entidades dado. Por ejemplo, la fecha de nacimiento de una persona puede ser una fecha cualquiera anterior a la fecha actual. El dominio de las fechas de nacimiento, entonces, es el subconjunto de fechas que son anteriores (o iguales, en algunos casos) a la fecha de hoy. El dominio de los nmeros de telfono, en Chile, podra ser una cadena de caracteres que cumpliera con el formato (XX) XXX-XXXX (simplificado), donde las X son dgitos. En general los dominios sern ms bien amplios, aunque cuando se lleva a cabo la implementacin es preferible restringir los dominios lo ms posible de manera que el gestor de bases de datos automticamente haga algunas verificaciones sobre los datos que se almacenan, para asegurar la integridad de los datos. Veremos cmo hacer esto en la seccin siguiente. Algunos atributos de un conjunto de entidades son especiales. De partida es necesario definir cules de ellos son opcionales y cules son obligatorios. Como el nombre lo indica, un atributo obligatorio es aquel que siempre debe estar definido para toda entidad. Un atributo opcional, en cambio, puede quedar sin definir para algunas de las entidades del conjunto de entidades. En general, es deseable que la mayor cantidad de atributos posible se definan como obligatorios, puesto que permite simplificar mucho algunas operaciones, al tiempo que
asegura una mejor integridad de los datos. Veremos ms sobre esto en la seccin siguiente. Otro concepto importante relacionado con los atributos es el de las llaves. Una superllave de una entidad es un atributo o conjunto de atributos que permite distinguir de modo nico cada entidad dentro de un conjunto de entidades. Por ejemplo, el nombre y RUT de una persona sera una superllave. Slo el nombre no podra serlo, puesto que dos personas pueden tener el mismo nombre. Un conjunto de entidades puede tener ms de una superllave; otra superllave para personas podra ser el nombre, la fecha de nacimiento y la direccin postal, puesto que es muy improbable que dos personas hayan nacido el mismo da, vivan en la misma casa y se llamen igual; pero omitiendo cualquiera de esos atributos es razonable esperar encontrar coincidencias. Adems, una superllave puede contener ms atributos de los necesarios para identificar unvocamente cada entidad. Eliminando los atributos innecesarios de las superllaves se obtienen las llaves candidatas. Por ejemplo, en el caso del nombre y RUT, usando slo el RUT servira tambin como superllave, y por lo tanto como llave candidata. Observe que todos los atributos que forman una llave candidata son obligatorios, puesto que si falta alguno, no es posible identificar completamente la entidad. Finalmente, se escoge una de las llaves candidatas y se designa como llave primaria del conjunto de entidades. Algunos conjuntos de entidades pueden no tener atributos suficientes para formar una llave primaria. En este caso, se dice que es un conjunto de entidades dbil. Un ejemplo claro sera un modelo para almacenar facturas de venta de bienes o servicios. Cada factura en s es una entidad fuerte; cada lnea dentro de una factura es una entidad dbil, puesto que no se puede identificar una lnea en particular sino en tanto pertenece a una factura. As cada factura tendra una lnea nmero 1, una lnea nmero 2, etc; por lo tanto, hablamos de una lnea en particular como la lnea nmero 5 de la factura nmero 18.289. En nuestro ejemplo anterior, todos los conjuntos de entidades son fuertes, puesto que sus elementos cuentan con los atributos suficientes para ser identificados unvocamente. Para ilustrar este nuevo concepto, incluiremos en nuestro modelo los datos de los experimentos que se publican en cada artculo para obtener observaciones sobre las hiptesis que los autores plantean. Cada artculo puede utilizar uno, ninguno o varios experimentos; algunos experimentos sern similares o iguales entre artculos; no hay ningn cdigo asociado intrnsecamente a un experimento, ni modo alguno de distinguirlos de forma
unvoca entre todos los artculos. Pero dentro de cada artculo, cada experimento es nico. As, un experimento tendr un atributo obligatorio que le permitir ser discriminado de entre el conjunto de experimentos de un mismo artculo (por ejemplo, el nmero que el mismo autor le asigna en el artculo). La figura 5 ilustra el nuevo diagrama E-R. Observe que el conjunto de entidades de experimentos se ha marcado como un rectngulo doble, lo cual indica que es dbil.
Con respecto a las llaves primarias de nuestro modelo de ejemplo, los conjuntos de entidades fuertes tienen por definicin llaves primarias. Sin embargo, en muchos casos estas llaves primarias son complejas de implementar. En el caso de las personas chilenas, usar el RUT es una eleccin natural. Para personas de otros pases, la eleccin se torna complicada: se podra escoger como llave primaria un nmero identificador por pas en conjunto con el pas que emite dicho nmero. Este esquema puede verse en problemas si existe algn pas que no emite
nmeros identificadores para sus habitantes. Asimismo, identificar un artculo es complejo: el uso del ttulo no es suficiente, puesto que otro artculo podra llevar el mismo ttulo. Una eleccin tericamente mejor sera el uso del resumen como llave primaria, eleccin que en la prctica es irrisoria cuando menos. Para resolver este problema prctico agregaremos a cada una de estos conjuntos un identificador numrico, ficticio, nico dentro de cada conjunto de entidades, independiente de cada uno de los identificadores de los otros conjuntos. Este identificador se generar internamente en la base de datos, y no tendr ningn significado fuera de ella. Una convencin usual es ponerle el nombre del conjunto de entidades, en singular, seguido de id, como en autor_id.
En el desarrollo de software para empresas, el almacenamiento de la informacin de un modo organizado es fundamental la mayora de los casos en los que el programador contesta no se puede hacer a un requerimiento de un cliente se debe a un error en el modelado de la base de datos que funciona como soporte a la aplicacin. En este artculo voy a intentar explicar, con un ejemplo prctico, un buen modelado de datos. Como, de alguna forma, estamos especializados en el software de gestin de empresas de enseanza, voy a utilizar un ejemplo de uno de esos modelos: la gestin de matriculacin de los alumnos, incluyendo los recibos que tienen que pagar, y el pago parcial de los mismos. Voy a explicar en este artculo el funcionamiento del proceso (para que podamos hacer el seguimiento de la implementacin), las tablas que utilizamos y los campos (de forma resumida) que componen cada una de las tablas. De paso, dar una idea de los ndices, procedimientos almacenados y triggers que nos pueden resultar tiles para que el rendimiento de la base de datos sea bueno.
ms nos conviene, el horario al que vamos a asistir, y con esta informacin nos matriculamos. Como forma de pago, en este caso, vamos a utilizar un pago mensual, y queremos que se nos domicilie el pago a travs de nuestra cuenta bancaria. En la academia, llegado este punto, introducen en su sistema de informacin nuestros datos y nos imprimen el contrato de prestacin de servicios, en el que se incluyen todos nuestros datos, el curso en el que nos hemos matriculado y todos los pagos que vamos a tener que realizar mientras estemos matriculados. Nos piden, de paso, que paguemos una reserva de plaza, que es una pequea cantidad del primer recibo. En el siguiente da de clase, nos presentamos, y el profesor comprueba en su hoja de asistencia que estamos incluidos en el grupo nos da la bienvenida, y empezamos a estudiar.
El modelo de datos
A partir de aqu har una descripcin de la estructura de tablas y columnas para almacenar la informacin de este proceso. Primero, algunas generalidades sobre cmo crear los campos.
Generalidades
Hay algunas cosas bsicas a la hora de modelizar el modelo de datos que usamos como convenciones (nomenclatura, cosas as). Por ejemplo: 1. La clave primaria de las tablas siempre es un identificador autoincremental. Todas las tablas tienen as un identificador interno, mantenido por el sistema. As, las claves ajenas son ms fciles de mantener. 2. En general, nosotros no solemos poner campos requeridos preferimos hacer la gestin dentro de la lgica de negocio. Nunca se sabe lo que te vas a encontrar, y se nos han dado casos de campos de los que estbamos completamente seguros que eran requeridos y hemos tenido que quitar la marca. 3. No se duplica informacin. Es decir, una de las reglas bsica es que la misma informacin no puede estar en dos sitios, salvo 4. En muchos casos, creamos campos calculados, que permiten acceder de forma rpida a informacin por ejemplo, el importe pendiente de un recibo, en realidad, se calcula como el importe total del recibo menos la suma de los pagos parciales como hacer este clculo cada vez que nos hace falta ralentiza el funcionamiento del sistema, hacemos un campo
calculado que se mantiene automticamente (en nuestro caso, a travs de Triggers de la base de datos). La informacin est duplicada en dos sitios, s, pero por motivos de rendimiento (y siempre est sincronizada). 5. En los nombres de los campos no ponemos caracteres especiales (ni acentos, ni espacios, etc.). Aunque el gestor de base de datos lo admita, no lo hacemos, porque luego nunca se sabe desde dnde vas a tener que acceder.
Cursos: almacena la oferta formativa del centro. Representa el catlogo o folleto que te dan al llegar al centro. Formas de Pago: para cada curso, las distintas opciones de pago que existen (es parte del folleto tambin). Trimestral, mensual, anual, etc. Grupos: dentro de cada curso, los diferentes horarios a los que se puede asistir. En este caso, el modelo que utilizamos es bastante ms complejo que el que voy a describir aqu en un artculo posterior lo describir en detalle.
o o
Clientes: el que paga puede ser el mismo que el alumno, pero tambin puede que no. Medios de pago: Contiene los diferentes mtodos que los clientes pueden usar para pagar (contado, domicilacin bancaria, etc), incluyendo las cuentas bancarias del cliente.
Alumnos: la gente que va a clase. Los clientes pueden ser empresas (personas jurdicas), los alumnos son personas fsicas. Un mismo cliente puede tener mltiples alumnos.
o o o
Matrculas: Refleja en qu curso nos matriculamos, las fechas, la forma de pago, etc. De forma fsica, se refleja en el contrato que te dan para firmar. Recibos: almacena los recibos que el cliente tiene que pagar (o ha pagado) en el centro. Pagos: esta tabla refleja los pagos que el cliente ha hecho (un recibo no necesariamente se paga de una vez). Como antes, la gestin de recibos y pagos que hacemos en realidad es ms compleja de lo que voy a describir aqu. En otro artculo har una descripcin ms completa.
Alumnos en grupos: refleja los alumnos que estn asignados a los distintos grupos. El alumno puede cambiar de grupo, y no queremos perder esa informacin histrica, as que necesitamos una tabla para gestionarlo.
Con PK se marcan las claves primarias, y con FK, las claves ajenas algunas lneas se cruzan, no lo puedo evitar. Las flechas indican que una tabla es hija de otra, con la punta de flecha apuntando al padre.
Como podis ver, slo estn indicados los campos que forman el modelo de datos las claves primarias y las claves ajenas, que en cualquier caso deben estar ocultas al usuario final. En la siguiente seccin describiremos los campos de cada tabla.
Cursos
o o
nombre: varchar(100) descripcion: Memo. Se utilizar, en el contrato que se imprime para el cliente, para hacer una descripcin larga del curso en el que el alumno se est matriculando. En uno de los sistemas que tenemos, en lugar de tener un campo memo, tenemos una tabla separada en la que se guardan, por tipologas, distintos campos memo, que se imprimen en distintos lugares del contrato.
o o
Formas de pago
o o o
nombre: varchar(100) importe: float. Es el importe de cada recibo que se cobrar numero_meses: integer. El nmero de meses de cada recibo. Si es 1, se crear un recibo cada mes mientras dure la matriculacin, si es 3, uno cada tres meses, etc. En algn sistema hemos hecho, en lugar de esto, una estructura de plantillas de recibos, con fechas, descripciones, etc. personalizadas. Eso permite ms flexibilidad y ms control, pero el modelo es bastante ms complejo.
o o o
numero_orden: integer. A la hora de presentrselo al cliente, poder mostrar primero las que ms nos interesen. importe_matricula: float. Si adems del importe del curso hay un importe de matrcula, se marca aqu. concepto_matricula. El concepto del recibo de matrcula, si creamos uno.
Grupos
o
nombre: varchar(100)
codigo: varchar(20). Siempre viene bien tener una codificacin adems del nombre. Por ejemplo, en algunos sistemas lo utilizamos para guardar el cdigo del grupo en la Fundacin Tripartita.
o o
fecha_inicio: date fecha_fin: date. Por defecto, las del curso al que pertenece el grupo, y adems estas fechas no pueden estar fuera de las fechas del curso al que pertenecen.
o o o
lugar: varchar(100) de imparticin del grupo. En general, hacemos una gestin de aulas, pero eso lo ampliar en otro artculo. notas: memo, del grupo horario: varchar(100) del grupo. En realidad, el horario se trata como una tabla por debajo de esta, pero no voy a entrar en tanto nivel de detalle ahora.
o o
maximo_alumnos: Integer. Mximo nmero de alumnos permitidos en el grupo. numero_alumnos: Integer. Es el nmero de alumnos existentes en el grupo. Este campo es de slo lectura para el usuario, y es calculado, a travs de una serie de Triggers en la base de datos, para poder saber rpidamente el nmero de alumnos activos en cada grupo sin tener que estar sumando.
Clientes
o
nombre: varchar(100). En nuestros sistemas, normalmente, este es el nico campo requerido (por cdigo, no en la base) que tenemos. As, el usuario puede dar de alta el registro aunque no tenga todos los datos, y volver despus.
o o o
primer_apellido: varchar(100) segundo_apellido: varchar(100) nombre_completo: varchar(300): Esto es un campo calculado, que se mantiene con Triggers, para poder coger de forma rpida el conjunto Nombre+ +primer_apellido+ +segundo_apellido
o o
direccion: memo codigo_postal: varchar(20): no hay que ser tacao de vez en cuando hay que meter una direccin extranjera y el cdigo postal puede ser ms grande.
o o o
poblacion: varchar(50) notas_internas: memo etc. de datos personales (profesin, telfonos, email, etc.)
Alumnos
o o o o o
nombre: varchar(100). Lo mismo que en clientes, pero lo requerido es nombre y primer apellido (en clientes es slo nombre por si primer_apellido: varchar(100) segundo_apellido: varchar(100) nombre_completo: varchar(300): etc. de datos personales (profesin, telfonos, email, etc.)
Medios de pago
o o o o o o o o
tipo_medio: Integer. Normalmente tiene una tabla asociada con los tipos de medios de pago, que suelen ser: Sin Pago, Contado, Banco nombre_titular: varchar(100) direccion_titular: memo entidad: varchar(4) oficina: varchar(4) dc: varchar(2) numero_cuenta: varchar(10). Si el tipo_medio es banco, entonces se tiene que rellenar la informacin bancaria del cliente. por_defecto: boolean. Se suele preguntar el medio de pago, pero teniendo uno por defecto, para no tener que rellenarlo siempre. Normalmente, cada cliente, al crearse, se crea un medio de pago contado, y se le pone por defecto.
Matrculas
Adems de los datos de curso, forma de pago, medio de pago, alumno y cliente (esto ltimo puede parece redundante, pero no lo es podemos tener el caso (yo lo he visto) de un alumno que se matricula para estudiar, digamos, ingls y francs el ingls lo paga el padre y el francs la madre. As, es necesario que cada matrcula est asociada con el alumno, y tambin con el cliente), necesitamos los siguientes campos:
o o o
fecha_inicio: date. fecha_fin: date. Por defecto, las del curso, pero hay gente que puede matricularse despus o terminar antes (si se da de baja, por ejemplo). importe: real. Por defecto, el de la forma de pago escogida, pero puede ser tambin distinto descuentos por familiares, cosas as. Suele ser buena idea dejarlo abierto, para que el cliente lo pueda cambiar.
motivo_baja: varchar(100). Normalmente, los motivos de baja son una tabla separada, para luego poder obtener estadsticas de nmero de bajas por tipo, cosas as.
Recibos
o o o o o o
fecha_emision: date fecha_cobro_completo: date numero_recibo: varchar(20) concepto: varchar(50) importe_recibo: float. importe_pendiente: float. Es un campo de slo lectura, actualizado a travs de triggers, que permite acceder a la informacin sin tener que sumar.
Pagos
o o o
fecha: date importe: real forma_cobro: varchar(20). Normalmente es una tabla separada, igual que el caso de los tipos de baja. Puede ser: contado, transferencia, tarjeta, taln, etc.
Alumnos en grupos
o o
fecha_inicio: date fecha_fin: date. Suele ser una interseccin entre la duracin del grupo y la de la matrcula, pero cuando el alumno cambia de grupo, para una matrcula puede haber varios registros de alumnos en grupos. Hay que tener en cuenta tambin la posibilidad de que en un mismo curso, pagando ms, un alumno pueda asistir a varios grupos (esto tambin lo he visto).
Actualizacin de los campos NombreCompleto de alumnos y clientes: normalmente, es un trigger BEFORE INSERT y BEFORE UPDATE, que actualiza el campo en base al contenido del nombre y los apellidos.
Actualizacin del campo ImportePagado de recibos, AFTER INSERT, UPDATE y DELETE de pagos, que actualiza el campo ImportePendiente de recibos como la suma de los pagos de ese recibo.
Es habitual hacer un procedimiento CREARRECIBOS, que se ejecuta en el proceso de creacin de la matrcula (o un trigger AFTER INSERT), que crea los recibos de la matrcula en base al importe y forma de pago seleccionadas.
En las prximas semanas continuar esta serie de artculos, describiendo otros submodelos de sistemas que hemos desarrollado algunas ideas que tengo: 1. Gestin de horarios y citas 2. Facturacin 3. Gestin de horas trabajadas 4. Stock Cualquier otra idea ser bienvenida
29 Comentarios Avanza 2 Puesta en marcha Networking profesional, la crisis como excusa para hacer buenos amigos
Modelo relacional
El modelo relacional para la gestin de una base de datos es un modelo de datos basado en la lgica de predicados y en la teora de conjuntos. Es el modelo ms utilizado en la actualidad para modelar problemas reales y administrar datos dinmicamente. Tras ser postuladas sus bases en 1970 por Edgar Frank Codd, de los laboratorios IBM en San Jos (California), no tard en consolidarse como un nuevo paradigma en los modelos de base de datos.
Su idea fundamental es el uso de relaciones. Estas relaciones podran considerarse en forma lgica como conjuntos de datos llamados tuplas. Pese a que sta es la teora de las bases de datos relacionales creadas por Edgar Frank Codd, la mayora de las veces se conceptualiza de una manera ms fcil de imaginar, esto es, pensando en cada relacin como si fuese una tabla que est compuesta por registros (cada fila de la tabla sera un registro o tupla), y columnas (tambin llamadas campos).
ndice
[ocultar]
1 Descripcin
o o
Nombre de los atributos (o campos) de la relacin y sus dominios; el dominio de un atributo o campo define los valores permitidos para el mismo, equivalente al tipo de dato por ejemplo character, integer, date, string...
Ciertos caracteres y nmeros (una sola columna de una sola fila). Algunas o todas las filas con todas o algunas columnas
Cada fila es una tupla. El nmero de filas es llamado cardinalidad. El nmero de columnas es llamado aridad o grado.
Una base de datos relacional es un conjunto de una o ms tablas estructuradas en registros (lneas) y campos (columnas), que se vinculan entre s por un campo en comn, en ambos casos posee las mismas caractersticas como por ejemplo el nombre de campo, tipo y longitud; a este campo generalmente se le denomina ID, identificador o clave. A esta manera de construir bases de datos se le denomina modelo relacional. Estrictamente hablando el trmino se refiere a una coleccin especfica de datos pero a menudo se le usa, en forma errnea como sinnimo del software usado para gestionar esa coleccin de datos. Ese software se conoce como SGBD (sistema gestor de base de datos) relacional o RDBMS (del ingls relational database management system). Las bases de datos relacionales pasan por un proceso al que se le conoce como normalizacin de una base de datos, el cual es entendido como el proceso necesario para que una base de datos sea utilizada de manera ptima. Entre las ventajas de este modelo estn: 1. Garantiza herramientas para evitar la duplicidad de registros, a travs de campos claves o llaves. 2. Garantiza la integridad referencial: As al eliminar un registro elimina todos los registros relacionados dependientes.
3.
Modelo relacional
3.1 Introduccin
En el captulo anterior se mencionaron 3 tipos de modelado: conceptual, lgico y fsico. El modelo e-r se considera un modelo conceptual ya que permite a un nivel alto el ver con claridad la informacin utilizada en algun problema o negocio. En este captulo nos concentraremos en desarrollar un buen modelo "lgico" que se conoce como "esquema de la base de datos" (database schema) a partir del cual se podr realizar el modelado fsico en el DBMS, es importante mencionar que es un paso necesario, no se puede partir de un modelo conceptual para realizar un fsico.
Creando un conjunto de tablas iniciales y aplicar operaciones de normalizacin hasta conseguir el esquema ms ptimo. Las tcnicas de nomalizacin se explican ms adelante en este captulo. Convertir el diagrama e-r a tablas y posteriormente aplicar tambin operaciones de normalizacin hasta conseguir el esquema ptimo.
La primer tcnica fue de las primeras en existir y, como es de suponerse, la segunda al ser ms reciente es mucho ms conveniente en varios aspectos:
El partir de un diagrama visual es muy til para apreciar los detalles, de ah que se llame modelo conceptual. El crear las tablas iniciales es mucho ms simple a travs de las reglas de conversin. Se podra pensar que es lo mismo porque finalmente hay que "normalizar" las tablas de todas formas, pero la ventaja de partir del modelo e-r es que la "normalizacin" es mnima por lo general. Lo anterior tiene otra ventaja, an cuando se normalice de manera deficiente, se garantiza un esquema aceptable, en la primer tcnica no es as.
Relacin Pelculas
La relacin Pelculas tiene la intencin de manejar la informacin de las instancias en la entidad Pelculas, cada rengln corresponde a una entidad pelcula y cada columna corresponde a uno de los atributos de la entidad. Sin embargo las relaciones pueden representar ms que entidades, como se explicar ms adelante. 3.3.2 Atributos Los atributos son las columnas de un relacin y describen caractersticas particulares de ella. 3.3.3 Esquemas Es el nombre que se le da a una relacin y el conjunto de atributos en ella. Pelculas (ttulo, ao, duracin, tipo) En un modelo relacin, un diseo consiste de uno o ms esquemas, a este conjunto se le conoce como "esquema relacional de base de datos" (relational database schema) o simplemente "esquema de base de datos" (database schema) 3.3.4 Tuplas Cada uno de los renglones en una relacin conteniendo valores para cada uno de los atributos. (Star Wars, 1977, 124, color) 3.3.5 Dominios Se debe considerar que cada atributo (columna) debe ser atmico, es decir, que no sea divisible, no se puede pensar en un atributo como un "registro" o "estructura" de datos. 3.3.6 Representaciones equivalentes de una relacin Las relaciones son un conjunto de tuplas, no una lista de tuplas. El orden en que aparecen las tuplas es irrelevante.
3.4 Conversin del modelo e-r a un esquema de base de datos (Conversin a tablas)
3.4.1 Introduccin El modelo es una representacin visual que grficamente nos da una perspectiva de como se encuentran los datos involucrados en un proyecto u organizacin. Pero el modelo no nos presenta propiamente una instancia de los datos, un ejemplo que muestre con claridad algunas datos de muestra y como se relacionan en realidad. Por eso es conveniente crear un "esquema", el cual consiste de tablas las cuales en sus renglones (tuplas) contienen instancias de los datos. 3.4.2 Conversin a tablas desde un modelo con relaciones (11,1-m,m-m) Las tablas siguientes muestran las reglas que se deben seguir para poder crear dicho esquema.
una tabla por cada conjunto de entidades o nombre de tabla = nombre de conjunto de entidades una tabla por cada conjunto de relaciones m-m o nombre de tabla = nombre de conjunto de relaciones definicin de columnas para cada tabla o conjuntos fuertes de entidades columnas = nombre de atributos o conjuntos dbiles de entidades columnas = llave_primaria (dominante) U atributos(subordinado) o conjunto de relaciones R (m-m) entre A, B columnas (R) = llave_primaria (A) U llave_primaria (B) U atributos(R) o conjunto de relaciones R (1-1) entre A y B columnas (A) = atribs(A) U llave primaria(B) U atributos(R) o conjunto de relaciones R (1-m) entre A y B columnas (B) = atribs(B) U llave primaria(A) U atributos(R)
A
LLP_A atribs_A
B1
LLP_B1
atribs_B1
B2
LLP_B2 atribs_B2 LLP_A attribs_rel_2
B3
LLP_B3 atribs_B3 LLP_A atribs_rel_3
A_B1
LLP_A LLP_B1 atribs_rel_1
Ejemplo:
escuela
id url nombre
departamento
clave url nombre id_escuela
curso
clave seccion nombre clave_depto
profesor
id nombre extension
estudiante
id nombre carrera
profesor_curso
id_prof clave_curso seccion_curso
estudiante_curso
id_estud clave_curso seccion_curso
crear una tabla para el conjunto de entidades A de mayor nivel columnas (A) = atributos(A) para cada conjunto de entidades B de menor nivel, crear una tabla tal que: columns (B) = atributos (B) U llave_primaria (A)
2.
o
si A es un conjunto de entidades de mayor nivel para cada conjunto de entidades B de menor nivel, crear una tabla tal que: columnas (B) = atributos (B) U atributos (A)
B1
atribs_B1 LLP_A
B2
atribs_B2 LLP_A
B3
atribs_B3 LLP_A
2) B1
atribs_B1 LLP_A atribs_A
B2
atribs_B2 LLP_A atribs_A
B3
atribs_B3 LLP_A atribs_A
Es importante mencionar que a pesar de que existen 2 mtodos para convertir una generalizacin a tablas, no hay una regla exacta de cual usar en determinado caso. A continuacin se mencionan algunos consejos tiles para la determinacin de cual mtodo emplear: 1. Si la entidad de nivel superior est relacionada con otra(s) entidades puede sugerirse emplear el mtodo (1) ya que de esa manera la tabla (A) ser la nica involucrada en la relacin, de otra
forma se tendran tres tablas (B1,B2 y B3) formando parte de la relacin 2. Es importante tomar en cuenta la pertenencia de instancias, si se considera que hablamos de una generalizacin disjunta, donde no se puede pertenecer a varias entidades de nivel inferior, quizs sea recomendable el mtodo (1), en otro caso se podra pensar en el mtodo (2). 3. Tambin es importante analizar ambos casos con respecto a las "consultas" que se deseen realizar ya que esto tambin determina en muchos casos el mtodo a emplear. 3.4.4 Descubrimiento de llaves en las relaciones Las llaves resultantes en las relaciones de un esquema se pueden inferir de la siguiente manera: 1) Cada tabla que provenga de una entidad contiene por si misma una llave 2) Para las tablas resultado de una relacin se toman las llaves primarias de ambas entidades y stas conforman la nueva llave primaria, excepto en un caso como el que sigue:
Podemos observar que existe una relacin m-m entre "actor" y "serie", demostrando que un actor puede actuar en muchas series y que muchas series tendrn a los mismos actores. La tabla que se creara sera: actor_serie
id_actor Joaqun Pardav id_serie Gnesis Qu bonita familia Gnesis id_personaje Abel hermano bueno Dulce abuelita Can hermano
si se considera "id_actor, id_serie" como la llave primaria caemos en un problema porque esa combinacin no identifica de manera nica a la tupla, como es el caso de "Joaqun Pardav, Gnesis" ya que en la primer tupla tenemos que determina a "Abel hermano bueno" y en la tercera a "Can hermano malo". La relacin es correcta ya que un actor puede representar a varios personajes en la misma obra, pero entonces la llave "id_actor, id_serie" no es la correcta y en este caso lo ms recomendable sera emplear los tres atributos de la relacin "id_actor, id_serie, id_personaje"
3.5 Normalizacin
Una vez creadas las tablas hay que verificarlas y revisar si an se puede reducir u optimizar de alguna manera. Los problemas tales como la redundancia que ocurren cuando se abarrotan demasiados datos en un sola relacin son llamados anomalas. Los principales tipos son: 1. Redundancia: la informacin se repite innecesariamente en muchas tuplas. En la relacin siguiente, length y filmType. 2. Anomalas de actualizacin: cuando al cambiar la informacin en una tupla se descuida el actualizarla en otra. Si en la relacin encontramos que el length de StarWars es 125 podramos cambiarlo nicamente para la primer tupla y olvidar actualizar las dems. 3. Anomalas de eliminacin: si un conjunto de valores llegan a estar vacos y se llega a perder informacin relacionada como un efecto de la eliminacin. Si eliminamos al actor Emilio Estevez, perdemos tambin la tupla de la pelcula MightyDucks.
year length filmType studioName starName 1977 1977 1977 124 124 124 104 95 95 color color color color color color Fox Fox Fox Disney Paramount Paramount Carrie Fisher Mark Hamill Harrison Ford Emilio Estevez Dana Carvey Mike Meyers
3.5.1.1 Definicin
En el diseo de esquemas de bases de datos el concepto de dependencia funcional (functional dependency) es vital para eliminar "redundancia", otros factores sera el manejo de dependencias multivaluadas y las restricciones de integridad referencial. Una dependencia funcional en una relacin R es una enunciado de la forma "si dos tuplas de R concuerdan en los atributos A1,A2,...An (tienen B y se dice que "A1, A2,....An determina funcionalmente a B".
los mismos valores para cada atributo), entonces deben concordar tambin con otro atributo B" . Esta FD se escribira como A1,A2,....An -->
Por otro lado, si un conjunto de atributos A1,A2...An determina funcionalmente a ms de un atributo, A1, A2, ... An ---> B1 A1, A2, ... An ---> B2 A1, A2, ... An ---> Bm entonces podemos simplemente escribir este conjunto de FDs como: A1, A2, ...An ---> B1,B2,...Bm
Star Wars
1977 124
color
Fox
1977 124
color
Fox
1991 104
color
Disney
1992 95
color
Paramount
1992 95
color
Paramount
title, year --> length title, year --> filmType title, year --> studioName title, year -/-> starName podemos entonces afirmar que: title, year --> length, filmType, studioName Quizs las dependencias funcionales ms evidentes sean las llaves. Decimos que un conjunto { A1, A2,....An } es una llave de un relacin si: 1. Esos atributos determinan funcionalmente a "todos" los dems atributos de una relacin.
2. No hay un subconjunto de { A1, A2,....An } que determine funcionalmente a "todos" los dems atributos (incluyendo al resto del conjunto { A1, A2,....An }) La definicin anterior de llave es similar a la que se mencion anteriormente de superllave, sin embargo las superllaves no son llaves "mnimas", recordemos que una llave primaria se escoge de entre el conjunto de superllaves mnimas. Es importante hacer notar que una llave mnima no se refiere al nmero de atributos includos, se puede tener una llave mnima ABC y otra DE donde ambas son mnimas an cuando una de ellas sea todava de menor tamao que la otra. Al conjunto de dependencia funcionales de una relacin R se le denominar F.
un conjunto de atributos --> * --> y es un conjunto de atributos --> y --> entonces -->
*Nota:
De manera general una dependencia funcional de la forma > se considera "dependencia funcional trivial" si
--
Si al menos algn elemento de no pertenece a se considera una dependencia no trivial. Si ningn elemento de pertenece a entonces se considera una dependencia completamente no trivial
--> -->
-->
Pseudotransitividad: si >
-->
-->
entonces
--
, si
--
,F
teniendo R (A,B,C,D,E,F) y F las dependencias: AB-->C, BC-->AD, D-->E, CF-->B. Comprobar que {A,B}+ ={A,B,C,D,E}
Si {A,B}+ = {A,B,C,D,E,F} entonces podramos afirmar que AB es superllave, pero para ello sera necesaria alguna dependencia adicional ej. AB --> CF El calcular la cerradura es empleado para:
Verificar si es una superllave, calculando + y revisando si + contiene a todos los atributos de la relacin R. Verificar una dependencia funcional --> (es decir, si pertenece a F+) checando si +. Calcular F+ (la cerradura de todo el conjunto de dependencias F en una relacin R): Para cada R se calcula + y para cada elemento S + se obtiene una dependencia funcional --> S.
3.5.2 Primera forma normal Una tabla se encuentra en 1a NF, si todos sus atributos son atmicos (indivisibles) El ejemplo clsico:
nombre direccin telfono
En 1a. NF
nombre apellido_paterno apellido_materno direccin telfono
3.5.3 Segunda forma normal Una tabla se encuentra en 2a NF, si est en 1a NF y cada atributo que NO es llave es "completamente" dependiente de la llave. Si tenemos la tabla:
calificaciones_cursos
id_estudiante depto clave_curso descripcin calificacin
NO se encuentra en 2a NF ya que { id,clave,depto} --> descripcin {clave,depto} --> descripcin Analizando todas las dependencias funcionales: { id,clave,depto} --> descripcin {clave,depto} --> descripcin { id,clave,depto} --> calificacin Para realizar la normalizacin (2NF) la relacin se descompondra en:
curso
depto clave_curso descripcin
estud_curso
id depto clave_curso calificacin
Al descomponer una relacin R en varias relaciones R1 y R2 se debe verificar que no haya prdidas, es decir, que al volver a combinar las relaciones (producto entre R1 y R2) se obtengan exactamente las mismas tuplas. Decimos entonces que para una descomposicin en R1 y R2 no hay prdida si: { R1 R2 --> R1 } F+
o bien si { R1 R2 --> R2 } F+
F={ { id,clave,depto} --> descripcin, {clave,depto} --> descripcin, { id,clave,depto} --> calificacin } tiene F+= { { id,clave,depto} --> id,clave,depto,descripcin,calificacin, {clave,depto} --> descripcin } y dicha relacin se descompone en:
depto clave_curso descripcin
id_estudiante
depto
clave_curso
calificacin
donde R1 R2 = depto,clave_curso donde depto,clave_curso ->descripcin y {depto,clave_curso -->descripcin} { { id,clave,depto} --> id,clave,depto,descripcin,calificacin, {clave,depto} --> descripcin }
3.5.5 Preservacin de dependencias Al descomponer una relacin R en varias relaciones R1,R2,..Rn es importante revisar que se preserven las dependencias funcionales iniciales. De esta manera se garantiza que una actualizacin no provoque una relacin invlida, verificando las FDs o bien a travs de combinaciones de relaciones(productos o joins) aunque esto ltimo no es muy eficiente. Para ello se analizan todas la dependencias funcionales Fi para cada Ri que debern ser un subconjunto de F+ De manera que F' = F1 F2 ...Fn
y la preservacin se verifica si F'+= F+ para el ejemplo anterior teniendo: F={ { id,clave,depto} --> descripcin, {clave,depto} --> descripcin, { id,clave,depto} --> calificacin } F+= { { id,clave,depto} --> id,clave,depto,descripcin,calificacin, {clave,depto} --> descripcin } F1= depto,clave_curso--> descripcin F2= id_estudiante,depto,clave_curso --> calificacin F' = F1 F2
F'+= { { id,clave,depto} --> id,clave,depto,descripcin,calificacin, {clave,depto} --> descripcin } y como F'+= F+ entonces si hay preservacin de dependencias.
3.5.6.1 Caractersticas
Un esquema relacional se encuentra en BCNF si para toda dependencia funcional X --> A:
result= {R} done=false calcular F+ while (! done) do if(existe un esquema Ri en result que no est en BCNF) then si no trivial en Ri --> es una dependencia funcional tal que est en F+ y else done=true end =0 result= ( result - Ri ) ( Ri ) ( , ) --> Ri no
Ejemplo: R(A,B,C,D)
B--> C
B-->D (B)+ = {CD}
La superllave sera {AB} por lo tanto no cumple con BCNF (B-->CD y B no es superllave). Descomponiendo usando B-->CD (A,B) (B,C,D) Esta ltima en BCNF
3.5.7.1 Caractersticas
Un esquema relacional se encuentra en 3NF si para toda dependencia funcional X --> A:
A es miembro de una llave candidata de R Lo anterior no quiere decir que una sola llave candidata deba contener a todos los atributos de A, cada atributo de A puede estar contenido en llaves candidatas diferentes.
Se puede observar que las 2 primeras restricciones son las mismas que para BCNF pero existe una tercera que da flexibilidad a las relaciones.
Podemos afirmar entonces que: "Si una relacin est en BCNF, est tambin 3NF; pero si una relacin est en 3NF no necesariamente est en BCNF". ejemplo, dada la relacin
branch-name customer-name banker-name office-number
banker-name --> branch-name office-number customer-name branch-name --> banker-name Se puede observar {customer-name branch-name} determina al resto de los atributos as que es la superllave de R. No est en 3NF porque:
Las DFs no son triviales En la primer dependencia, "banker-name" no es superllave de R Se puede observar que office-number y banker-name no son parte de alguna llave candidata
se descompondra en:
banker-name branch-name office-number
customer-name branch-name --> banker-name banker-name --> branch-name Esta descomposicin si est en 3NF porque:
No hay dependencias funcionales triviales En la segunda relacin, la segunda DF no cumple que banker-name es superllave
En la segunda relacin, la segunda DF, branch-name es miembro de la llave candidata {customer-name, branch-name}
Al cumplirse la 3er regla se confirma que la descomposicin est en 3NF. Se puede observar que al no cumplir con las 2 primeras no est en BCNF pero gracias al relajamiento si est en 3NF Otro ejemplo:
deptos
nombre_depto extensin id_jefe
Las DFs no son triviales En la dependencia "nombre_depto-->id_jefe" de la segunda relacin, "nombre_depto" no es superllave de R Se puede observar nuevamente para la segunda relacin que id_jefe no es parte de alguna llave candidata
Aplicando la descomposicin:
deptos
nombre_depto extensin id_jefe
Se observa como la relacin no solo est en 3NF sino tambin en BCNF por cumplir con la segunda regla.
3.5.7.2 Algoritmo general de descomposicin tratando de alcanzar 3NF 3.5.7.2.1 Forma cannica de las FDs (Fc)
La forma cannica de F es aquel conjunto mnimo de dependencias funcionales equivalentes a F, sin dependencias redundantes o partes redundantes de dependencias. Para obtener la Fc se deben extraer todos los miembros "extraos", suponga un conjunto F de dependencias funcionales y la dependencia --> est en F.
si A -->
y }) {( - A ) --> }
B es extrao en AB --> C porque { A --> C, AB --> C } lgicamente implica A --> C (el resultado de quitar B de AB --> C ).
El atributo A es extrao en si A el conjunto de dependencias (F - { implica lgicamente a F Ejemplo: F = { A --> C , AB --> CD}
y -->
})
--> (
-A)}
C es extrao en AB --> CD porque A B --> C puede ser inferido an despus de eliminar C Test para verificar si un atributo es extrao Dado un conjunto de dependencias F y
-->
est en F
Para verificar si A
o o
calcular ( {
verificar si ( { } - A )+ contiene a , si lo hace entonces A es extrao Para verificar si A es extrao en o calcular + usando solo las dependencias en: F'=(F - {
o
-->
})
--> (
- A) }
verificar si
1. Para cada dependencia X --> Y en Fc, crear una relacin Ri (X,Y) 2. Si ninguna de las Ris contiene una de las superllaves de la relacin, crear Ri(X) donde X es una de las superllaves de la relacin original 3. Si Ri y Rj tienen una llave en comn, mezclar Ri y Rj 4. Eliminar relaciones redundantes
*El algoritmo anterior garantiza que en una descomposicin no haya prdida (al incluir por lo menos en una relacin una de las superllaves) y que se preserven las dependencias funcionales (al incluir cada una de ellas). Ejemplo:
sid name street city zip
student Fc: sid -->name,street,city street, city-->zip zip --> city Descomponer en 3NF 1. 2. 3. 4. R1(sid, name, street, city), R2(zip, street, city), R3(zip, city) Eliminar R3
sid name street city
R1 sid -->name,street,city
zip street city
Como se mencion anteriormente: "Si una relacin est en BCNF, est tambin 3NF; pero si una relacin est en 3NF no necesariamente est en BCNF". En la prctica la mayora de los esquemas en 3NF tambin estn en BCNF, contraejemplo: (Sucursal, Cliente, Banquero) banquero --> sucursal sucursal, cliente --> banquero est en 3NF pero no en BCNF puesto que "banquero" no es una superllave, normalizando: suc-banquero (sucursal, banquero) suc-cliente (sucursal, cliente) Nuevamente se presentan las prdidas de dependencias Qu es mejor ? BCNF o 3NF ?
De manera general se puede decir que ambas son buenas. El caso ideal es conseguir BCNF sin prdidas y con preservacin de dependencias. Si se alcanza BCNF pero no hay preservacin de dependencias se puede considerar una 3NF (recordando que 3NF siempre debe carecer de prdidas y debe preservar dependencias).
3.6 Conclusiones
De manera que las metas del diseo de bases de datos con dependencias funcionales son:
* Llegar a una forma BCNF puede llegar a ser complicado, debido a esto en muchas ocasiones es suficiente con