Contactar con el cliente: Carga inicial de datos

[fransaiz95]

Abordar con el cliente las dudas correspondientes a la BBDD y pedir un fichero para una primera carga inicial de datos.

[alvarag]

Esta tarde voy a hablar con él, ¿puedes colgar aquí el diseño actual del E/R y el relacional?

[fransaiz95]

Esto es lo que hablamos el otro día y dejamos pendiente en la otra Issue Campos de la tabla:

TABLE Country { idCountry
levelDetail

TABLE Region { idRegion
idCountry
levelDetail
demand
RenForecast
DemForecast

TABLE Technology { idTechnology
ExiCapacity
CapacityCost
GenerationCost
CapEmployment
GenEmployment
EnvImpact
GenEmission
CapacityEff

TABLE Fuel { idFuel
resAvailable
fuelCost
fuelNational

TABLE Year { idYear

TABLE Line { idLine
idRegionOrigin
idRegionDestiny exiLine
lineCost
flowCost
lineEmployment
flowEmployment
lineEfficiency

Modelo ER:

Explicación:

• Un pais tiene regiones (de momento solo tendremos México)
• Las regiones se comunican con arcos (un arco une dos regiones)
• Las regiones tienen tecnologías (plantas de producción)
• Cada planta de producción (tecnología) consume un determinado combustible
• La relación de año con todas las tablas es debido a que un año existen unas plantas y al siguiente puede haber otras (un histórico).

Jesús nos propuso la siguiente aclaración:

Los de los arcos es una reflexiva de libro

Region N--------N Region

y conecta es la entidad Arc Para que encaje el tipo tendriamos quizás que irnos a una ternaria ¿?

Region N--------N Region .........................| ........................N .................TypeLine

Y generaria una unica tabla Conecta en lugar de las 3 tablas que se deducen del diagrama ( Arc y las 2 relaciones N:N en las que interviene Arc). Hay una clave en conecta (idRegionOrigen, idRegionDestino, idTipoLinea)

Habria que preguntar si:

a) Entre un origen y destino sólo puede haber un tipo de línea??

Region N--------N Region ........................| ...................... 1 ..................TypeLine En ese caso la clave es sólo (idRegionOrigen, idRegionDestino)

a) Los arcos son bidireccionales (tiene importancia la distincion entre origen y destino??) (Se puede añadir un check en SQL, check(idOrigen<idDestino) para evitar meter el arco inverso...)

Por otro lado no esta claro si la tabla Line representa la entidad TypeLine, Arc y/o algunas relaciones

Lo del año lo entiendo pero no lo acabo de ver con ese encaje. Necesitariamos saber exactamente cuales de todos los datos son fijos y cuales son susceptibles de cambiar anualmente antes de dar otra vuelta al diagrama

[alvarag]

Tengo las ideas mucho más claras, desaparecen algunas relaciones y van a aparecer otras. Mañana concreto con Jesús y te lo dejaré escrito aquí.

[fransaiz95]

Perfecto, gracias Alvar

[alvarag]

Tenemos el diagrama mucho más claro ahora mismo, de hecho queda muy vistoso con una relación ISA, unas entidades débiles... Perfecto para un examen de BBDD ;)

Hay que pasar a limpio este diagrama ER y luego hacer el relacional.

En el paso al relacional, hay varias tablas de relaciones N a N que van a desaparecer, ejs:

• RangeRen: el inicio fin del rango/intervalo serán atributos de la nueva tabla que aparece en esa relación entre Renewable y Region
• Renewable y Fossil desaparecen, solo existirá Technology que tendrá un atributo booleano que será Renewable.
• Tanto en la demanda como en la información meteorológica, la clave pasará a la relación y no serán entidades por si mismas puesto que son débiles.

Atributos por cada tabla: Fuel:

• idFuel: alfanumérico de 10.
• fueCos: numérico 6.2 (6 enteros, 2 decimales)
• production: numérico 12.0

Country:

• idPais: alfanumérico de 3.
• name: alfanumérico de 100.

FuelTech:

• power: 10.2
• percCon: 3.2
• fueCon: 3.2

Technology:

• idTechnology: alfanumérico de 10.
• name: alfanumérico de 50.
• renewable: booleano
• WatWit: numérico 15.0
• GencoPri: num 3.4
• Cap: 10.0
• NewCapCos: 15.0
• ManCos: 10.2
• ManCosNewCap: 10.0
• GenCos: 3.4
• GenCosNewCap:3.4
• Lifetime: 3.0
• GHGEmi: 3.4
• InvCapEmp: 3.2
• ManCapEmp: 3.2
• DecCamEmp: 3.2
• OMCapEmp: 3.2
• FueCapEmp: 3.2
• WatCon: 15.0
• WatWit: 15.0

RegionTech:

• Power: 10.2
• CapAva: 10.2

RangeRen:

• GenAva: 3.4

Region:

• idRegion: num 5.0
• name: alfa 100
• DemFor: 3.4
• RenFor: 3.4

Arc:

• Ni: región inicial 5.0
• Nf: región final 5.0
• distance: 5.0

TypeLine:

• LinCap: 7.2
• NewLinCos: 10.2
• ManLinCos: 10.2
• FloCos: 5.2
• NewLinEmp: 5.2
• ManLinEmp: 5.2
• FloEmp: 5.2
• EffLin: 1.4

ArcType:

• NumLines: 3.0

RangeDem:

• demand: 8.2

RangeMeteo:

• temp: 3.2
• wind: 3.2
• hum: 3.2

Nota: No he metido las claves foráneas que tienen que ir fruto de las relaciones.

[jmaudes]

Como cuando estabamos cambiado de version de diagrama hemos tenido que cortar repentinamente porque comenzaba una reunion, hay cosas del diagrama viejo que se han quedado en el nuevo. Corrijo:

RangoMeteo es una entidad débil y por tanto es la parte N de una ralacion 1:N con Region. Por lo que los atributos wind, humidity y tº son de la entidad débil y no en el rombo (esta asi porque al principio lo pinte como una relacion N:M y no nos dio tiempo a corregirlo)

Lo mismo nos paso con RangoDemanda, es la parte N de una ralacion 1:N con Region. Por lo que el atributo demand es de la entidad debil y no es de la relacion

Cuando lo pases a tablas, la entidad RangoRenovable es una de esas entidades en las que podemos prescindir de la tabla y quitarla simplificando (ver el apartado de representación de la dimension temporal en la seccion de las ternarias en el tema del modelo E/R en los apuntes de segundo)

Ya siento el lio

[alvarag]

Gracias por las aclaraciones Jesús

[fransaiz95]

Gracias por toda la información, a ver si con esto y los apuntes se hacer el diagrama correctamente.

Muchas gracias!

[fransaiz95]

Buenas tardes, si he entendido bien todo, el diagrama ER pasado a limpio sería:

[alvarag]

Creo que se han quedado muchos "GenAva" fruto del copy&paste...

¿Hoy hemos quedado a la tarde?

[fransaiz95]

Cierto, es verdad... Ahora lo corrijo. Me he despistado. Si, a las 17:45 me paso por la uni

[fransaiz95]

ER CORREGIDO:

[alvarag]

Haz el paso a relacional para poder enseñárnoslo luego y repasar si está correcto

[fransaiz95]

Buenas. Revisando las tablas que me quedarían al convertir el modelo ER, hecho en falta la tabla auxiliar "Region-RangeRen" al ver la relacion N----N entre las dos tablas. Aunque la tabla RangeRen hemos dicho que desaparece, cual es el criterio para no crear esta tabla? O es que si que hay que crearla.

[alvarag]

Si no recuerdo mal, finalmente quedarán las siguientes tablas:

• Technology (con el booleano que indica si es renovable).
• RegionTechnology: para todas las tecnologías "sucias".
• RangeRen: que recibe la clave de technology y de region.

[fransaiz95]

Si, esas son las tablas que quedaría, pero realizando el proceso para llegar hasta ahí, a mi me surge "la necesidad" de la otra tabla que he dicho. Lo que no entiendo es por qué no hay que crearla.

[jmaudes]

Hola No hay una relación binaria Region-RangeRen (sobra la N en rojo, perdón)

Lo que hay es una ternaria entre ReneWable-RangeRen-Region que es del tipo N:M:P o si quieres N:N:N de los apuntes.

En el tema del diagrama entidad-relación, teníamos una sección 7.4 titulada "7.4. Las interrelaciones ternarias como forma de modelado temporal en el Diagrama E/R"

Había 2 casos: que la entidad que expresa tiempo representa el tiempo generase tabla o que no la generase. Dice al final de la sección que el caso que genera tabla esta asociado a "cuando ese acontecimiento temporal se quiere reservar, como cuando se reserva una cita en una agenda. Si los huecos posibles de la agenda son filas de una tabla contra la que existe una clave ajena, obligamos a que el hueco esté dado de alta primero, evitando que los acontecimientos sucedan en instantes no permitidos por la agenda". Por ejemplo, las fechas de un torneo, si tienes una tabla fechas fuerzas a que las fechas sólo sean las de esa tabla y nadie se equivoque poniendo un partido en una fecha no permitida, quizás sean 20 fechas en todo el año ...

Más adelante dice "Sin embargo, hay situaciones que piden a gritos la aproximación contraria, son aquellas en las que la dimensión temporal es cotidiana e imprevisible, y por tanto bien no merece la pena, o bien es imposible registrar y/o saber de antemano en que fecha van a suceder los acontecimientos.", es decir al ser imprevisible, si mantienes una tabla de fechas, tienes que insertar todas las fechas del año(s), pues todas son posibles, y el interés/ventaja de la tabla de fechas, que es restringir las fechas posibles, se pierde/no existe.

En este caso teóricamente todos los días del año se prodece electricidad con energías renovables, luego tampoco ganamos nada en tener una tabla de fechas.

[jmaudes]

Completando el comentario de Alvar RangeRen: recibe la clave AJENA de technology y de region, y tiene la clave primaria compuesta Clave de Technology + Clave de Region + Clave de la entidad RangeRen (que como hemos comentado no llegamos a convertir en tabla)

Esto es así porque es el caso de ternaria N:N:N en el que entre otras cosas, debemos permitir que se repitan filas con la misma tecnología y región siempre que cambie el rango

Tambien dijimos que podíamos asumir que nunca 2 rangos comenzarían a la vez, luego bastaba la fecha o momento de inicio para identificarlos y no es necesario identificarlos con el par fecha inicio - fecha fin

[fransaiz95]

Vale, entendido. Entonces, quedaría algo así:

Es correcto?

[jmaudes]

Dale otra vuelta y leete bien lo que te he puesto antes Repasa si es necesario la asignatura de Bases de Datos de segundo (da la impresion de que no tienes muy claro que es una entidad débil, que es una reflexiva, y la ternaria estas cerca pero no esta bien)

Tablas que aún estan mal

region_itechnology rangeMeteo rangeDemand arc