Las bases para crear una BD sólida?

[zero0097]

De antemano gracias por leer =)


Bueno yo he llevado materias de BD pero me quejo por que siempre me ponían a hacer resúmenes, y los únicos ejemplos que hacíamos era de producto vendedor, nunca hicimos mas de 3 tablas en clase....

Después iba con un amigo que había reprobado la materia, yo lo iba también (pero si la había pasado) y la clase de ese profe la hizo mas chida, vimos los de innodb, como se afecta en cascada todo, vio trigers, procedures, incluso nos pidió un programa que gestionara una base de datos (yo uso Java) y todo bien....... aprendí mucho con el, pero las bases no las aprendí..

apenas si se como se usa el Diagrama E-R, no se sobre como se representan las cardinalidades en la BD, tengo problemas para abstraer las entidades de un problema real...

y quisiera ayuda en este aspecto ya sea con una basta explicacion o links que hablen al respecto.....

por ejemplo se que la Primary Key debe ser un valor UNICO e Irrepetible para cada registro de la tabla, que otros trucos hay?

pero por ejemplo como identifico las relaciones si son N:N o 1:N o 1:1...... es lo mismo N:1 que 1:N?...

como se lee? por ejemplo alumnos-materias, ambas son entidades no?

los alumnos, pues tienen matricula, nombre, telefono, materias, calificaciones
las materias tiene, id o clave, nombre, lugar o aula, alumnos y calificaciones?

entonces tengo que hacer una tabla de materias y una de alumnos no? pero que pasa con los campos de calificaciones por ejemplo no creo que se deba de poner en ambas tablas o si?, el atributo calificaciones pertenece a alumnos o a materias?.... y como hago la relación..

-un alumno tiene una materia? pues como que no, por que tiene varias, aunque se puede dar.
-un alumno tiene varias materias? esta si queda
-varios alumnos tienen varias materias? esta también queda
-varios alumnos tienen una materia? también queda!!

como se cual es la buena, y como se representan en la BD, una vez si leí que para una relación de muchos a muchos se hacia una tabla intermedia, pero no decía como, osea aquí en este ejemplo la haría con que campos? con la matricula y la clave de materia? y como se representan las demás restricciones de cardinalidad en una base de datos, osea N:N es una tabla intermedia, y las otras?

Saludos y gracias por su ayuda, básicamente quiero que me digan cuales son las bases, osea primero esto, luego esto y esto, y cuidado con hacer esto por que puede pasar esto otro... etc... gracias!

[genihe]

Hola, como estas? Mira, yo estoy bastante parecido a vos, casi la misma situación. Recurro mucho a internet y a investigar los concepto que no tengo claro. ¿Esto es difícil? claro que si!!!, ya que no hay un tutor virtual que te guie cuando estas en situaciones asi, pero si se investiga por cuenta propia los concepto "colgados", aqui, en este foro; que estoy agradecido de que exista, podemos compartir y de a poco entre todos ir mejorando nuestros conocimientos.
Empiza por buscar los conseptos que no conoces o tienes curiosidad, conocer que algo existe es un gran avance para empezar, y conforme investigues veras nuevos conseptos los cuales tendras que investigar.
Siempre tendras que remontarte una y otra vez sobre tus pasos, esa es la manera de aprender y afianzan.
Te paso un link que me parece interesante.
http://www.programacionfacil.com/mysql/start
Al menos para el tema N:N o 1:N o 1:1
Saludos!

[zero0097]

Gracias, la única relación que tengo clara es la de muchos a muchos, las demás aun no comprendo como se realizan cuando ya se crea una BD, pero hay voy, encontré también este link muy bueno =).. http://mysql.conclase.net/curso/?cap=000#

[gnzsoloyo]

Lamento mucho escuchar que has tenido tan malas experiencias con los profesores en cuyas manos ha quedado la enseñanza de un tema tan crítico como el de las bases de datos. Y no es una exageración decir "crítico", si consideras que más allá de las aplicaciones de diseño, multimedia, juegos y un largo etcétera, donde más se usa la informática es precisamente para procesar... datos.
Todos son datos en este mundo, y todo dato implica base de datos. Y si las mismas están mal diseñadas, parafraseando a un profesor mío, solamente consigues basura.

Bueno, las preguntas que tienes son muchas, por lo que tendremos que empezar por las básicas:

por ejemplo se que la Primary Key debe ser un valor UNICO e Irrepetible para cada registro de la tabla, que otros trucos hay?

No hay truco, el modelo establece cierta reglas a cumplir:
1) Toda entidad y tabla tienen una única PK.
2) No puede ser nula.
3) Es irrepetible.
4) Identifica unívocamente un registro en una tabla (o tupla en la relación/entidad).

Fuera de eso, en la definición del paradigma se enseña que una PK debe ser un atributo de la entidad, o un subconjunto de atributos considerados como unidad, tal que pueda identificar a esa tupla en todo el universo de tuplas posibles. Y por universo se enseña que se habla de todos los casos, aún los que no existen aún en esa base de datos.
Esto significa que una PK debería definirse preferentemente con alguno de los atributos de la entidad que le sean propios, y no crear uno ad hoc.

Pero cuando se extiende un poco el tema, se reconoce que no en todos los casos es posible encontrar un atributo o subgrupo que pueda cumplir con ese papel, en esos caso (y sólo como excepción) el modelo expresa que se puede crear un atributo para ser usado como PK en tanto cumpla con las reglas.
Este es el caso muy usado de los ID numéricos incrementales. No son obligatorios, son soluciones fáciles para no realizar buenos análisis, muy comunes especialmente entre programadores (lamento si alguien se ofende, pero es verdad).
Si el modelo lo permite, siempre es mejor usar un atributo propio de la entidad como PK. Si no se puede, y luego de la pertinente normalización de las tablas hasta la 3FN, se puede usar otra cosa.

pero por ejemplo como identifico las relaciones si son N:N o 1:N o 1:1...... es lo mismo N:1 que 1:N?...

La identificación de las cardinalidades se hace en dos momentos:
1) En el análisis previo, cuando se está modelando el sistema, y jamás cuando se crea el modelo físico.
2) Durante la normalización, ya que allí se generan tablas que no existen en el modelo lógico.

En el análisis previo surgen no sólo casi todas las cardinalidades, sino que además surge si esas relaciones son mandatorias u opcionales, estableciendo si se trata de entidades débiles o fuertes.

En cualquier caso, la cardinalidad se analiza "parándose" desde la óptica de cada entidad y expresando la regla que define esa relación.

Por ejemplo:

"Cada A tiene una única relación con un sólo B."

Cardinalidad 1:1 mandatoria.

"B puede tener cero o más de A relcionados."

Cardinalidad 1:N opcional.

"B tiene uno o más de A relcionados."

Cardinalidad 1:N mandatoria

"A se relaciona con cero o más de C."
"C se relaciona con cero o más de A."

Cardinalidad N:N opcional.

"A se debe relacionar con uno o más de C."
"C se debe relacionar con uno o más de A."

Cardinalidad N:N mandatoria.

Nota: Toda relación N:N obligatoriamente genera una tabla física para administrarla, que no existe en el modelo lógico, y cuya PK está formada por las PK de cada una de las tablas relacionadas en ella.
Sólo se agrega un atributo discriminador como parte de la PK si y sólo si además de ser N:N, en la relación el mismo par de PKs puedan aparecer N veces también.

¿Se entiende eso?

En cuanto a 1:N y N:1, por reflexividad, son equivalentes. Sólo explicitan la diferencia en el diagrama acerca de cuál de las dos entidades es 1 y cuál N.

[zero0097]

Muchas gracias por tu explicación =), me gustaría saber como es que se manipulan las entidades fuertes y débiles....

Por ejemplo, la tabla trabajador:

atributos:
-matricula
-nombre
-telefono de casa
-telefono de trabajo
- telefono de celular
- telefono de fax

en este caso se hace una tabla de Telefonos, no? y entonces sería una entidad débil por que nececita del trabajador para existir o tener un sentido, entonces, si esta es una tabla diferente a trabajador, como asocio 2 entidades, (fuerte-debil)... las tablas quedan asi?

trabajador
-matricula
-nombre

telefono
-matricula
-telefono de casa
-telefono de trabajo
- telefono de celular
- telefono de fax

y la relación de las tablas seria por la matricula? un trabajador tiene un numero (uno de cada cosa) y un número telefonico, solo le pertenece a un trabajador......entonces la relación es 1 a 1? o es 1 a N por que son 4 telefonos?

de antemano gracias =)