Ir a contenido


Necesito ayuda con base de datos


  • Por favor inicia una sesión para responder
47 respuestas en este tema
  • amok
  • Provincia:Sevilla


Hola compis.

Pues vi un post donde el compi galdor pedía ayuda con base de datos.

Así que aprovecho por si pudierais ayudarme a mi también.

El caso es que tengo que entregar un proyecto a finales de mes y no tengo ni papa.

He hecho el modelo relacional, pero no se si estará bien planteado.

Si quereis os pongo una captura y ya me comentáis.

Me vendría de lujo vuestra ayuda.

Escrito 06 febrero 2017 - 16:03        Editado por amok, 06 febrero 2017 - 16:05.



  • Maxmalkav
  • Provincia:Sevilla


Si tienes tiempo (comentas que hasta final de mes), pide hora de tutorías con el profesor de turno, prepara la sesión de antemano: mira lo que tienes, divide el trabajo en partes más pequeñas y formula tus dudas de manera específica.

 

No es lo mismo que llegues con tu modelo relacional diciendo: "no sé si está bien" , a que llegues y digas "entre la tabla X e Y no sé si la relación es la correcta", o "no sé como plantear las tablas que reflejen X, Y e Y".

 

Lo del hilo de Galdor lo veía como una emergencia, pero no es la forma de la que se saca más partido al ejercicio. Si tienes tiempo y la posibilidad no te lo pienses, tutorías (que para eso se las pagan al profesor y está obligado a darlas, al menos en la universidad ;-)

  • Valorado por lastMonkey

Escrito 06 febrero 2017 - 17:26


  • amok
  • Provincia:Sevilla


Si tienes tiempo (comentas que hasta final de mes), pide hora de tutorías con el profesor de turno, prepara la sesión de antemano: mira lo que tienes, divide el trabajo en partes más pequeñas y formula tus dudas de manera específica.

 

No es lo mismo que llegues con tu modelo relacional diciendo: "no sé si está bien" , a que llegues y digas "entre la tabla X e Y no sé si la relación es la correcta", o "no sé como plantear las tablas que reflejen X, Y e Y".

 

Lo del hilo de Galdor lo veía como una emergencia, pero no es la forma de la que se saca más partido al ejercicio. Si tienes tiempo y la posibilidad no te lo pienses, tutorías (que para eso se las pagan al profesor y está obligado a darlas, al menos en la universidad ;-)

 

Bueno, si pido ayuda es porque ya intenté varias veces que me explicase las dudas sin obtener un buen resultado.

 

De  hecho, en el primer trimestre me suspendió el proyecto sin apenas poderme defender y ahora está complicando las cosas mucho más. Y la forma que tengo de enterarme de las cosas es mirando videos de youtube.

 

Lo que estudio es un grado superior, y te aseguro que a algunos profesores les da igual que el alumnado se entere o no.

 

Su filosofía es que si de la clase de 25 tíos aprueban 2 no está tan mal.

 

En fin, tendré en cuenta tus consejos, gracias por la ayuda.


Escrito 06 febrero 2017 - 18:13


  • Maxmalkav
  • Provincia:Sevilla


 

Si tienes tiempo (comentas que hasta final de mes), pide hora de tutorías con el profesor de turno, prepara la sesión de antemano: mira lo que tienes, divide el trabajo en partes más pequeñas y formula tus dudas de manera específica.

 

No es lo mismo que llegues con tu modelo relacional diciendo: "no sé si está bien" , a que llegues y digas "entre la tabla X e Y no sé si la relación es la correcta", o "no sé como plantear las tablas que reflejen X, Y e Y".

 

Lo del hilo de Galdor lo veía como una emergencia, pero no es la forma de la que se saca más partido al ejercicio. Si tienes tiempo y la posibilidad no te lo pienses, tutorías (que para eso se las pagan al profesor y está obligado a darlas, al menos en la universidad ;-)

 

Bueno, si pido ayuda es porque ya intenté varias veces que me explicase las dudas sin obtener un buen resultado.

 

De  hecho, en el primer trimestre me suspendió el proyecto sin apenas poderme defender y ahora está complicando las cosas mucho más. Y la forma que tengo de enterarme de las cosas es mirando videos de youtube.

 

Lo que estudio es un grado superior, y te aseguro que a algunos profesores les da igual que el alumnado se entere o no.

 

Su filosofía es que si de la clase de 25 tíos aprueban 2 no está tan mal.

 

En fin, tendré en cuenta tus consejos, gracias por la ayuda.

 

 

Si la opción de las tutorías no es viable (desgraciadamente hay profesores que se empeñan en ser malos profesores), usa el foro como tutoría, creo que tendrás mejores resultados de nuestra ayuda si empiezas desmenuzando tus dudas. Mientras más concreta la consulta, creo que mejor ayuda obtendrás (divide y vencerás).

 

Yo no estoy muy puesto en base de datos (creo es lo normal cuando las estudias y luego no haces uso intensivo en tu vida profesional), prueba a ir poniendo dudas en el hilo y vamos viendo ;-)


Escrito 06 febrero 2017 - 18:29        Editado por Maxmalkav, 06 febrero 2017 - 18:30.


  • amok
  • Provincia:Sevilla


Gracias compañero. ;)

 

Tampoco es que yo quiera abusar de vuestra buena fe  xD  Lo que pretendo es aprender por mi mismo, pero claro hay veces que te ponen muchos obstáculos...

 

Y  claro, he empezado pidiendo ayuda con el modelo ralacional porque si lo tienes mal, lo tendrás todo siempre mal.

 

En esto de las bbdd es muy importante empezar bien desde el principio.

 

La primara duda, es si veis fallos en el MR yo le he dado unas pocas vueltas, Pero no se si voy por buen camino.

 

Spoiler

Escrito 06 febrero 2017 - 19:15        Editado por amok, 06 febrero 2017 - 19:16.


  • Maxmalkav
  • Provincia:Sevilla


No acabo de pillar qué notación E-R estás usando. Parece notación de pie de Crow pero las flechas me despistan. ¿Qué software has usado para hacer el modelo? Yo en su día usé Chen. Lo importante es ajustarse a una representación concreta para que cualquiera que esté acostumbrado a ella la entienda sin problema y sin dobles interpretaciones.

Aquí tienes un resumen gráfico de las principales representaciones E-R: 

480px-ERD_Representation.svg.png


Volviendo a tu diagrama, empezaré por lo fácil, la relación entre las entidades Cliente, Particular y Empresa.
Si lo entiendo bien, un Cliente puede ser o bien una Empresa o bien un Particular, siempre será uno de los dos pero nunca ambos a la vez. Algunas observaciones:
  • Un Cliente tendrá como máximo 1 Particular asociado, pero cuando el Cliente sea una Empresa, significa que tendrá 0 Particulares asociados. Por tanto la cardinalidad en el lado de Particular creo que debería ser 0..1, esto es, todos tus Particulares tendrán un cliente asociado, pero no todos tus Clientes tendrán un Particular asociado.
  • Un Particular siempre tendrá asociado un Cliente, por lo tanto en el lado de Cliente la cardinalidad es 1.
  • De la misma forma que en (1), un Cliente siempre tendrá como máximo una Empresa asociada, o bien ninguna (si es un Particular), por lo tanto la cardinalidad en el lado de la Empresa es 0..1 (o estoy asociado a una única empresa o a ninguna)
  • Al igual que en (2), una Empresa siempre tendrá asociado un Cliente, cardinalidad 1 en el lado del Cliente.
Aquí llega la parte para la que la mayoría de diagramas E-R tienen problemas en expresar y es una relación que excluye a la otra (si soy un Particular no soy una Empresa y viceversa). No sé si esto es lo que representa la línea que corta las flechas que surgen de Particular y Empresa.
 
Mira a ver si mis comentarios cuadran con tu enunciado y con lo que quieres expresar con el diagrama.

Escrito 06 febrero 2017 - 22:50        Editado por Maxmalkav, 06 febrero 2017 - 22:51.


  • Maxmalkav
  • Provincia:Sevilla


Sobre la relación Factura / Cliente, comprendo que la flecha significa que la cardinalidad por parte del Cliente es 1.

Por otro lado, es posible tener un cliente sin ninguna factura en el sistema? Si es así, modificaría la cardinalidad del lado de la Factura para pasarla de 1..N a 0..N.


Escrito 06 febrero 2017 - 22:52


  • Maxmalkav
  • Provincia:Sevilla


Y por cierto, coméntame que convención estás usando para nombrar/definir las claves foráneas (foreign keys). Me acuerdo de los conceptos pero no estoy tan fino con la nomenclatura.


Escrito 06 febrero 2017 - 22:55


  • amok
  • Provincia:Sevilla


Gracias por la ayuda compañero. Creo que la notación es pie de Crow.

Quizás el modelo lógico este más claro que el relacional. Uso sqldeveloper para generar los modelos.

Las líneas que cortan particular y empresa es para indicar una herencia. Es como bien dices uno u otro pero nunca los dos, para ello está el atributo tipocli. Efectivamente la cardinalidad cliente factura es 1:n.

Algo parecido he hecho con la tabla empleado, es también una herencia. Las líneas discontinúas indican opcionalidad y la línea continua obligatoriedad. Pero se ve mejor en el lógico. Si quieres lo subo.

Ahora que lo veo, en la parte de factura debería ser continuo. Porque una factura debe tener a un dependiente y un dependiente puede tener una o varias facturas.

Las foreign keys se definen con F. Las Primary con P y las Primary foren con PF

Escrito 07 febrero 2017 - 00:31        Editado por amok, 07 febrero 2017 - 00:34.


  • Maxmalkav
  • Provincia:Sevilla


Quizás el modelo lógico este más claro que el relacional. Uso sqldeveloper para generar los modelos.

Yo entiendo el modelo de entidad-relación como modelo lógico, no sé si te refieres a otra cosa distinga aquí. No estoy puesto en cosas orientadas al desarrollo como el objeto-relacional. Sólo puedo hablarte (y no mucho) del diseño de base de datos.

Las líneas que cortan particular y empresa es para indicar una herencia. Es como bien dices uno u otro pero nunca los dos, para ello está el atributo tipocli. Efectivamente la cardinalidad cliente factura es 1:n.

No recuerdo haber visto la herencia para Entidad-Relación, he echado un vistazo a Wikipedia y la nombran como extensión para intentar cubrir algunas carencias del modelo E-R, si has visto situaciones parecidas resueltas así no tiene vuelta de hoja.

Ahora que lo veo, en la parte de factura debería ser continuo. Porque una factura debe tener a un dependiente y un dependiente puede tener una o varias facturas.

Soy un pesado de la cardinalidad, un estado posible/plausible es el de un dependiente sin ninguna factura asociada aún.

Las foreign keys se definen con F. Las Primary con P y las Primary foren con PF

Esa parte la estaba siguiendo bien, lo que no me queda claro en el gráfico a qué campos asocias las claves ajenas / foreign keys.
  • Valorado por amok

Escrito 07 febrero 2017 - 01:44


  • amok
  • Provincia:Sevilla


Yo entiendo el modelo de entidad-relación como modelo lógico, no sé si te refieres a otra cosa distinga aquí. No estoy puesto en cosas orientadas al desarrollo como el objeto-relacional. Sólo puedo hablarte (y no mucho) del diseño de base de datos.

 

 

 

Bueno, en la aplicación que yo uso primero hago el modelo lógico y luego se genera el relacional. Donde se crean las FK y PF y las nuevas entidades si hay relaciones n:n entre otras cosas.

 

Spoiler

No recuerdo haber visto la herencia para Entidad-Relación, he echado un vistazo a Wikipedia y la nombran como extensión para intentar cubrir algunas carencias del modelo E-R, si has visto situaciones parecidas resueltas así no tiene vuelta de hoja.

 

Si, básicamente es eso.

 

Soy un pesado de la cardinalidad, un estado posible/plausible es el de un dependiente sin ninguna factura asociada aún.

 

 

De pesado nada compañero. Efectivamente la cardinalidad es 0:n pero la aplicación sqldeveloper de oracle. No permite esa cardinalidad. (lo mínimo es 1) para ponerlo opcinal se debe indicar con las líneas discontinuas. En realidad donde veas lines discontinuas, querrá decir que de la parte de la entidad que sale, esta tiene 0 en su cardinalidad.
 

Esa parte la estaba siguiendo bien, lo que no me queda claro en el gráfico a qué campos asocias las claves ajenas / foreign keys.

 

Por ejemplo, en la tabla Cliente, existe la Primary IDCli está viaja a la tabla Factura como FK pero poniendole la tabla por delante: Cliente_IDCli. No se si es a eso a lo que te refieres.


Escrito 07 febrero 2017 - 14:38        Editado por amok, 07 febrero 2017 - 15:28.


  • Maxmalkav
  • Provincia:Sevilla


Sí, me refería a eso cuando hablaba de las FK.
Voy siguiendo ya más o menos el significado de símbolos del Sqldeveloper (Oracle es el MAL!).

Las relaciones entre Ténico, Empleado y Dependiente son las mismas que que la Cliente, así que creo que no hay mucho que decir al respecto de esas.

Intentaré echarle un vistazo más detenido al núcleo (Factura y demás) pero el modelo se ve medianamente correcto (luego además tiene que casar bien con el enunciado :-)
  • Valorado por amok

Escrito 07 febrero 2017 - 20:26


  • amok
  • Provincia:Sevilla


Sí, me refería a eso cuando hablaba de las FK.Voy siguiendo ya más o menos el significado de símbolos del Sqldeveloper (Oracle es el MAL!).Las relaciones entre Ténico, Empleado y Dependiente son las mismas que que la Cliente, así que creo que no hay mucho que decir al respecto de esas.Intentaré echarle un vistazo más detenido al núcleo (Factura y demás) pero el modelo se ve medianamente correcto (luego además tiene que casar bien con el enunciado :-)

La verdad que si, oracle es el mal xD


Respecto al enunciado, es un proyecto mio desde cero y mi forma de trabajar es haciendo primero el lógico y después el relacional.

Se que no es la forma correcta. Pero yo el enunciado lo hago una vez creado el relacional, osea ahora.

Básicamente es una tienda informática que vende componentes y tiene servicio técnico. Los empleados son dependientes y técnicos. Los dependientes realizan facturas y los técnicos servicios. Existen 2 típos de clientes particular y empresa a los que se le expenden facturas

Y los componentes tienen almacén origen y almacén destino.

Algo así sería.

Ojo te lo estoy escribiendo desde el móvil, debería estar mejor redactado. Pero creo que te puedes hacer una idea, no?

Pero vamos que si ves entidades que sobran o falten me lo puedes decir. Como te he dicho es un proyecto libre y yo le he dado vueltas y he pensado que algo así se podría llevar a la realidad.

Ahora me quedaría lo más complejo, consultas, subconsultas, triggers, procedures y esas cosas... Que es lo que peor llevo

Escrito 07 febrero 2017 - 22:34        Editado por amok, 07 febrero 2017 - 22:48.


  • Maxmalkav
  • Provincia:Sevilla


Hombre, entiendo que te sea más lógico empezar por el modelo lógico y luego definir el E-R, pero no es muy "natural" y no te fuerzas a trabajar de forma un poco más realista: requisitos, modelado de las entidades y relaciones, diseño lógico, implementación. Quizás al no seguir el orden algunas cosas quedarán un poco extrañas en el E-R.

 

Si es un proyecto que planteas desde cero, pues tienes libertad, con lo bueno y malo que conlleva. Sobre lo que pueda faltar y sobrar, creo que más que tener un modelo super realista que pueda ser usado mañana en una tienda, es cuestión de que tu proyecto tenga un modelo plausible y añadas buenos ejemplos de cosas que hayas visto en teoría (distintas cardinalidades, lo de la herencia, etc) y que hagas triggers y consultas lo suficientemente sofisticadas para mostrar lo que has aprendido.

 

Al menos yo valoraría eso a la hora de corregir una práctica/proyecto: no tiene por qué ser perfecto, pero quiero ver aquí y allá demostraciones prácticas de lo que has aprendido, al fin y al cabo es un ejercicio de habilidad y conocimiento.

 

Por tanto, si tu defines el enunciado, empezaría con los requisitos: por un lado los básicos de la tienda, y por otro, requisitos añadidos para lucir y hacer ver lo que sabes de la teoría. Exponiendo claramente lo que quieres y luego implementándolo queda un ejercicio académico más o menos redondo.

  • Valorado por amok

Escrito 08 febrero 2017 - 11:03


  • amok
  • Provincia:Sevilla


Bueno pues ahora se plantea un problema.

 

En la entidad DEPENDIENTE. Puse un atributo llamada BONIFICACIÓN de tipo number 7,2

 

La verdad que no se muy bien como hacer esto. Ya que las bonificaciones se suelen calcular por el tanto por ciento de ventas y me parece muy chapucero dejarlo sólo como para introducir un número desde la rejilla de datos.

 

La verdad que estoy ante un dilema


Escrito 09 febrero 2017 - 13:43



0 usuario(s) estan leyendo este tema

0 miembros, 0 invitados, 0 usuarios anónimos