Proyecto DAI

Yo tuve q hacer un proyecto sobre una tienda de moviles, donde habia proveedores clientes etc ec Conq yo creo que esta muy bien, veo q tienes algunas cosas q yo no toque xD

hacer transferencias a otras cuentas

#5 Pues me sería de grandísima ayuda porque los dfdŽs son mi mayor problema.

He acabado cogiéndoles miedo porque en el primer trimestre no me salía ninguno. Los hacía siguiendo una lógica pero el profesor siempre me decía que me faltaban burbujas o cualquier chorrada. Es imposible que un ejercicio de estos tenga una única solución.

Y lo mismo con los malditos Cuadros de Constantine. Cuando tenga el DFD y los pase a constantine, lo subiré por aquí a ver si está más o menos aceptable.

PD: He añadido la compra de acciones y algo básico que me ha dicho #4, las trasferencias a otras cuentas.

Gracias por vuestra ayuda!

#6

Los DFDs son horribles,a mí me queda sólo Ingeniería del Software y otra asignatura para terminar la carrera y la odio con toda mi alma.Tengo la sensación de que la mejor forma de aprobar es aprender a pensar los ejercicios como lo hace el profesor y eso me revienta.Es totalmente subjetivo el tema de los DFDs (tu puedes dar una solución al problema que esté bien y no sea la del profesor).De hecho mientras justifiques por que eliges una cosa u otra debería servir.

Por otra parte las funciones que has puesto de un banco están bien,si desarrollas todas te va a quedar un DFD bastante aceptable (contando luego diccionario de datos,diagramas E-R y toda la pesca).

#9 pues access para estos casos es lo mejor, xq es facil sencillo, puedes juntar la base de datos con la interfaz facilmente, y con cuatro pijadas de VB puedes hacerte cosas chulisimas xD sql requiere mas curro, y para un proyecto de mierda xa aprobar sobra

¿Alguien dijo que iba a usar Access como SGDB? Lo digo porque alguno parece que os estáis haciendo la picha un lio, y desviando el tema.

Solo dije que iba a tomar como ejemplo la BD de la ayuda de access..., su esquema digamos, pero bueno... seguid con vuestras paranoyas de access weno, access malou :\

Y no, no voy a usar Access, ni porque sea mejor ni peor, sino porque no me han pedido que lo haga en otro SGDB.

Y lo que pedia era simplemente eso, como seria el esquema de una base de datos de una aplicación de gestión de pedidos, facturas, albaranes, porque tengo una ligera idea, pero yo no soy contable, ni administrativo, y tengo muchas lagunas.

espero que os sirva para algo..

las restricciones van todas en cascada menos la de transaccion con sucursal y numero de cuenta, ya que debe de quedar un registro de movimientos, para saber donde ha ido a parar el dinero no creeis xdd

Sistema Gestor de Base de Datos.

¿qué tal? xDDD, a mi me da que regulín, regular, ... pero para ir empezando...

#19 si que existe pero no te deja implementarlo que es distinto...
o como piensas que vas a realizar movimientos donde se requieren 2 y solo 2 cuentas si no existe tal cardinalidad.
#17 cierto cachis... es numt la PK..

Muchas gracias a todos. Las relaciones están terminadas y parecen que funciona todo bien. Cuando quiero dar de alta una tarjeta de crédito y la vinculo a una cuenta que no es la que tiene el titular que yo le especifico, no puede hacerlo y eso es buena señal. Ahora voy a hacer formularios y demases.

#23:

No sé por que pierdo el tiempo en corregirte, teniendo en cuenta que cada vez que posteas lo haces para mezclar ignorancia con prepotencia, y de nuevo lo estás haciendo otra vez.

No existe un relación, 2,2 y de la forma en la que lo has planteado, para guardar una transacción, tendrías que crear 2 registros, uno para la cuenta de cargo (la que paga), y otro para la cuenta de abono (la que recibe el dinero). Esto es un error como una casa, ya que una de las normas básicas de una base de datos relacional es no duplicar información, y tú estas duplicando el mismo registro dos veces.

La forma correcta de hacerlo, es poner una columna más en la tabla de transacciones para tener la cuenta de abono, de forma que en un solo registro ya tienes las dos cuentas.

Ya te lo hemos dicho 3 personas, y vayas a donde vayas, cualquier persona que sepa un mínimo de diseño de bases de datos relacionales te va a decir que lo has hecho mal. Se te ha dicho de buena fe para que corrijas tus errores, aprendas, y sepas más, pero si tú quieres creerte más listo que nadie y no estás dispuesto a aceptar que lo has hehco mal y vas a insistir en que es como tú dices, allá tú.

#24 el no se explico bien. tu si y con coherencia.
pd: hasta los chulos damos las gracias.
#25 las cardinalidades estan hechas con el paint en modo de explicacion en el diagrama no es asi. solo decirte una cosa me importa un carajo tu opinion con tu comentario lo unico que demuestras es que te van a partir la boca muchas veces en tu vida si es que sales de tu agujero.

#24 asi lo decidi poner , tras tu comentario...
en transancion numt es la pk.

#26 Que yo sepa una cuenta esta asociada a una sucursal aunque no tenga ninguna transaccion, ¿ no ? y en ese dibujo yo veo una ternaria, si es que es una ternaria que no lo se.

Tambien veo que sucursal tiene un atributo ( clave ajena parece ) que es numero de cuenta, ¿ solo puede tener una ?

#15
Y eso de que con Access es mucho mas rapido que con sql, no se yo, los create tables son directos, y ya esta la bd montada.. :S

#17 En un esquema Entidad Relacion, NO EXISTEN LAS TABLAS ! Y por lo tanto, no hay claves primarias, si algun atributo sabes que es unico, pues puedes marcarlo como clave candidata.

#24 Existir si que existe la cardinalidad 2,2 : 0,N , lo que pasa es que las relaciones estan en el esquema ER y eso son tablas, una relacion 2,2 : 0,N , se traduciria (al pasar a tablas) en lo que tu bien has dicho, 2 columnas /atributos que son clave extranjera de la otra tabla.

Un ejemplo raro que se me ocurre:

Un deprabado puede tener varios trios, y cada uno de estos trios tiene que estar relacionado con un deprabado y con dos prostitutos.

Deprabado (0,1) --- (1,N) Trio-> ( 1,N) ----> (2,2) Prostitutos

Aqui las relaciones ( cuasi-tablas ) quedarian

Deprabado(idDepr, ... )
Trio ( idTrio, idDeprFK, idProstFK, idProst2FK, ... )
Prostituto(idProst, ... )

Madre mia que mal estoy.

Asi lo haria yo
Cliente es titular de una cuenta, y puede estar de copropietario ( segundo titular o los que sean ) entendiendo que puede haber varios en una misma cuenta.
Habria que tener una restriccion que dijera que no puede haber cuentas sin titular. ( Suelo poner restricciones de cardinalidades minimas pero para no liarlo.. )

Cli -> titular(1,1) -> Cuenta
Cli -> coprop(M,N) -> Cuenta

Las cuentas se hacen en una sucursal determinada que es la que cada uno tiene, en el numero de cuenta tienes numeros para el banco, sucursal, etc .. si se tuviera en cuenta, cuenta podria ser entidad debil.. o eso o sucursal y banco segun se mire que clave depende de que.

Cuenta -> situada(N,1) -> Sucursal
Sucursal -> perteneciente( N,1) -> Banco

En una cuenta se realizan operaciones
Cuenta -> se_realizan (1,N) -> Operacion

y todas las operaciones se realizan en alguna sucursal, aunque si no es necesario esto se podria eliminar , las operaciones por internet no se si tienen alguna sucursal o no, la verdad lo desconozco.
Operacion -> en ( N,1) -> Sucursal

Y queda todo relaciones 1:N preciosas menos la del cliente con cuenta, que si quieres hacerlo facil y sencillo, metes una 1:N también como por ahi arriba que una cuenta solo pueda tener un propietario y que un cliente pueda tener varias cuentas, tampoco es raro.

Ese atributo sigue estando mal a no ser que el usuario sea el gerente de la sucursal :S

Si la haces ternaria la haces cuaternaria con el banco tb asi queda mas bonito, pero yo prefiero poner más binarias y con alguna restriccion