23 respuestas en este tema

[egostar]

Bueno el título es, tal vez, demasiado audáz pero bueno, ya saben como soy de exagerado jajajaja

Pues bien, a raíz del hilo Empezar con buen pie una aplicación... me parece que sería un buen ejercicio cruzar ideas de como crear una base de datos y una vez que se tenga un concenso generalizado, proceder a crearla.

¿Que les parece?

Saludos

[Desart]

No me parece mala idea, pero para que sería la base de datos?

[poliburro]

En general lo ideal es identificar las entidades y su relación. Luego plasmarlo en un diaramama entidad relación. Yo uso visio para ello.

[egostar]

No me parece mala idea, pero para que sería la base de datos?

Bueno, esa es la idea, tener las bases para crear cualquier tipo de base de datos, es decir, ¿qué se debe tomar en cuenta para crear una base de datos independientemente de su motor y de su utilización?.

Sé que es muy amplio el espectro, pero debe haber algo que sirva de cimiento para una base de datos "perfecta"

Saludos

[egostar]

En general lo ideal es identificar las entidades y su relación. Luego plasmarlo en un diaramama entidad relación. Yo uso visio para ello.

Y cómo se puede identificar eso para alguien que está en cero, ¿ que debe de tomar en cuenta ?

Por ejemplo, cuando hice mi primer base de datos, en ese entonces con Xtrieve, comencé por dibujar literalmente(*) las pantallas de mi sistema y de ahí saqué los campos que necesitaba para cada pantalla.

(*) Literalmente a lápiz y papel, sí, era la ERA de D.O.S. y turbo pascal

Saludos

[genriquez]

Vamos a tener que hacer algo con Egostar, le está dando duro la edad. jejeje.  D.O.S. fue ayer nada más!

En cuanto al tema, para mi es importante la normalización, al menos hasta la tercera forma normal y saber bien cuales son las tablas que no se normalizan (Históricos).  Esto lo digo porque he visto muchas aplicaciones que no están bien normalizadas y luego tratan de hacer las cosas por código, generando más problema que soluciones.

No sé como explicar cuando hacerlo, pero la experiencia me dice que también hay que saber desnormalizar en algunos casos.

Espero sirva de algo este comentario.

[TiammatMX]

La Tormenta Perfecta, El Juego Perfecto, la base de datos perfecta..., ¿por qué ésa obsesión por algo que el ser humano no tiene? Más que "perfecta", yo diría "adecuada", especialmente cuando las necesidades, deseos y requisitos personales y empresariales son tan individuales como el folio del IFE...

Normalizar, es la palabra clave.

[poliburro]

¿Y si vamos creando la base de datos de un sistema X?

[egostar]

La Tormenta Perfecta, El Juego Perfecto, la base de datos perfecta..., ¿por qué ésa obsesión por algo que el ser humano no tiene? Más que "perfecta", yo diría "adecuada", especialmente cuando las necesidades, deseos y requisitos personales y empresariales son tan individuales como el folio del IFE...

Normalizar, es la palabra clave.

Por eso dije al principio que era demasiado audaz de mi parte, no es obsesión, me parece que hay personas mas obsesivas que yo, como tú comprenderás. 

¿ Nos puedes ilustrar como se normaliza un base de datos ? Digo, ese es el punto medular de éste hilo, compartir con los demás nuestras experiencias, si no pensaramos así DelphiAccess no tendría razón de ser, es un asunto de colectivo.

Saludos

[poliburro]

¿por qué ésa obsesión por algo que el ser humano no tiene?

¿El ser humano no es perfecto? Pues desde donde yo veo, somos un organismo con muchos procesos perfectos. El pensamiento, el torrente sanguíneo, el adn, la estructura de las manos. Etc  Y para mejor muestra de ello esto:

http://es.wikipedia....bre_de_Vitruvio

[egostar]

Vamos a tener que hacer algo con Egostar, le está dando duro la edad. jejeje.  D.O.S. fue ayer nada más!

Si caray, eso de llegar a 50 como que ya pesa

En cuanto al tema, para mi es importante la normalización, al menos hasta la tercera forma normal y saber bien cuales son las tablas que no se normalizan (Históricos).  Esto lo digo porque he visto muchas aplicaciones que no están bien normalizadas y luego tratan de hacer las cosas por código, generando más problema que soluciones.

No sé como explicar cuando hacerlo, pero la experiencia me dice que también hay que saber desnormalizar en algunos casos.

Espero sirva de algo este comentario.

Eso es lo que me parece interesante, es decir, no es hacer algo específico, sino contar con los elementos necesarios para abordar cualquier proyecto.

Saludos

[Delphius]

Hola,
Asi como no existe la pareja perfecta, lo mismo se puede decir de una base de datos. No existe LA DB perfecta. Más bien si se podría llegar a concebir una base de datos estable y equilibrada. Pero he aquí la cuestión ¿estable y equilibrada según la percepción de quien?
Cada base de datos es un mundo y su diseño está condicionado por el propio entendimiento y el análisis del contexto que el desarrollador ha llevado a cabo.
Como cada uno tiene su percepción entonces es de esperarse diversas expresiones... y todas ellas pueden ser lo suficientemente estables y equilibradas. No existe una base de datos bien y otra mal... simplemente podríamos llegar a decir que bajo ciertos parámetros técnicos-operativos podrían encontrarse ciertos elementos flojos que la hicieran menos estable.

Pero si hay técnicas que permiten llegar a un buen puerto. En primer lugar, saber como y cuando aplicar las reglas normales. Con llevar el diseño hasta la 3ra regla normal por lo general es suficiente.
Pero he aquí que hay situaciones, técnicas-operativas y hasta se pueden concebir de diseño, en las que seguir una normalización desmedida nos puede entorpecer algunas situaciones. En estos casos es bienvenido el concepto de desnormalización. Generalmente se opta por una desnormalización en casos de rendimiento cuando las bases de datos son muy grandes.

El análisis y diseño de una base de datos comienza, o debería comenzar, en las primeras etapas del ciclo de desarrollo. Es más, lo correcto sería llevar en paralelo el A+D tanto de la aplicación como de la base de datos. Dependiendo del paradigma/proceso/modelo de desarrollo (no confundir con el paradigma de programación) se pueden incorporar a sus actividades estructurales tareas específicas formales que se dediquen formalmente a este punto.
Por ejemplo en el Paradigma de Cascada existe la actividad estructural (1ra) llamada Análisis de Requisitos*. Es durante esta etapa y la siguiente (Diseño) cuando tiene lugar justamente el diseño de la base de datos.

En Recolección/Análisis de requisitos justamente se lleva a cabo un estudio del contexto y del ambiente. Se extraen y se reconocen las entidades, roles, relaciones. Con esto es posible concebir al menos un DER provisorio o temporal con el cual empezar.
Hay variadas técnicas para la recolección de los requisitos, entre algunas de esas están los Casos de Uso. El C.U no es más que una "historia" en donde se relata los procesos significativos que aportan valor de negocio. En el relato se pueden observar ciertas palabras claves que pueden ser de ayuda para detectar las posibles entidades.

Saludos,

*Diferentes bibliografías nombran a esta actividad. Algunas la llaman Recolección de requisitos. Y hasta se reconoce una actividad estructural previa (orden 0) que la denominan Ingeniería de requisitos.

[egostar]

Hola,
Asi como no existe la pareja perfecta, lo mismo se puede decir de una base de datos. No existe LA DB perfecta. Más bien si se podría llegar a concebir una base de datos estable y equilibrada. Pero he aquí la cuestión ¿estable y equilibrada según la percepción de quien?
Cada base de datos es un mundo y su diseño está condicionado por el propio entendimiento y el análisis del contexto que el desarrollador ha llevado a cabo.
Como cada uno tiene su percepción entonces es de esperarse diversas expresiones... y todas ellas pueden ser lo suficientemente estables y equilibradas. No existe una base de datos bien y otra mal... simplemente podríamos llegar a decir que bajo ciertos parámetros técnicos-operativos podrían encontrarse ciertos elementos flojos que la hicieran menos estable.

Pero si hay técnicas que permiten llegar a un buen puerto. En primer lugar, saber como y cuando aplicar las reglas normales. Con llevar el diseño hasta la 3ra regla normal por lo general es suficiente.
Pero he aquí que hay situaciones, técnicas-operativas y hasta se pueden concebir de diseño, en las que seguir una normalización desmedida nos puede entorpecer algunas situaciones. En estos casos es bienvenido el concepto de desnormalización. Generalmente se opta por una desnormalización en casos de rendimiento cuando las bases de datos son muy grandes.

El análisis y diseño de una base de datos comienza, o debería comenzar, en las primeras etapas del ciclo de desarrollo. Es más, lo correcto sería llevar en paralelo el A+D tanto de la aplicación como de la base de datos. Dependiendo del paradigma/proceso/modelo de desarrollo (no confundir con el paradigma de programación) se pueden incorporar a sus actividades estructurales tareas específicas formales que se dediquen formalmente a este punto.
Por ejemplo en el Paradigma de Cascada existe la actividad estructural (1ra) llamada Análisis de Requisitos*. Es durante esta etapa y la siguiente (Diseño) cuando tiene lugar justamente el diseño de la base de datos.

En Recolección/Análisis de requisitos justamente se lleva a cabo un estudio del contexto y del ambiente. Se extraen y se reconocen las entidades, roles, relaciones. Con esto es posible concebir al menos un DER provisorio o temporal con el cual empezar.
Hay variadas técnicas para la recolección de los requisitos, entre algunas de esas están los Casos de Uso. El C.U no es más que una "historia" en donde se relata los procesos significativos que aportan valor de negocio. En el relato se pueden observar ciertas palabras claves que pueden ser de ayuda para detectar las posibles entidades.

Saludos,

*Diferentes bibliografías nombran a esta actividad. Algunas la llaman Recolección de requisitos. Y hasta se reconoce una actividad estructural previa (orden 0) que la denominan Ingeniería de requisitos.

Pero..... ¿no hay nada que pueda yo tener como base para la creación de una base de datos que no me de problemas o que éstos sean mínimos?

Yo pienso que sí, siempre he creído que un buen sistema parte de una base de datos bien pensada, que durante el ciclo de vida se tenga que adicionar con modificaciones no previstas, eso me queda claro, pero,

¿No hay nada que hacer al respecto? ó ¿Debo conformarme con la frase "NOBODY IS PERFECT"?



Saludos

[poliburro]

¿No hay nada que hacer al respecto? ó ¿Debo conformarme con la frase "NOBODY IS PERFECT"?

Si lo hay amigo,  es cosa de seguir estas reglas: http://es.wikipedia.org/wiki/1NF

[Fenareth]

Yo lo que creo es que existen técnicas que te indican cómo tratar de evitar la mayoría de errores posibles al momento de diseñar una base de datos pero que al final se mezclan factores como: experiencia, capacidad de abstracción, requerimientos solicitados (que muchas veces el solicitante olvida un "pequeño" detallito), etc... lo que complica un mucho la creación de la perfección

Bueno, ni las recetas de cocina son ejecutadas igualmente por el chef 1 que por el chef 2, que pueden seguir paso a paso las instrucciones, pero cada uno bajo sus propias circunstancias, generan dos resultados diferentes...

Peor aún, si le preguntas a muchas personas lo que se tiene que tomar en consideración para hacer una base de datos perfecta, te acribillarán con tips y consejos que han ido obteniendo de sus propias experiencias (cada quien habla como le va en la feria) que a lo mejor se contraponen con lo que decía la teoría y pues ya se jodió la cosa...

En pocas palabras, no aporté más que más negatividad al hilo 



Saludox !

[Desart]

Yo creo que es una buena idea, pero creo que debe implementarse con otro hilo, escrito por los maestros, que debería tratar las diferentes  partes de lo que se va a tratar, me explico, se que esta la cara oculta x, que explica bien, los diferentes partes, pero como entenderéis, , en un momento determinado, buscar un concepto con una breve aclaración, se vuelve muchas veces difícil, más si no estas donde lo tienes y tienes que consultar algo, por lo que creo se debería iniciar la base de este hilo, sea o no perfecta, que por lo meno sea lo más útil y por otra abrir un nuevo hilo, que  trate los diversos temas, de una manera breve y simple que sirva de consulta y enseñanza (/yo mismo hay varios conceptos que aún no manejo), hablamos de que es por ejemplo

Una base de datos
tabla,
campos y tipos
view
Store produced,
SQL y sus comandos
Thread
Etc..

Creo que es un buen proyecto para realizar, que si se hace de una manera concisa y clara puede ser de mucha ayuda, al estar en un único lugar, de hecho se podria una vez estuviese avanzado, crear un pdf, con lo dado, para tenerlo en la biblioteca de cada uno.


Esta es mi opinión, la dejo a vuestra entera disposición, para que la tratéis.

[Delphius]

Pero..... ¿no hay nada que pueda yo tener como base para la creación de una base de datos que no me de problemas o que éstos sean mínimos?

Yo pienso que sí, siempre he creído que un buen sistema parte de una base de datos bien pensada, que durante el ciclo de vida se tenga que adicionar con modificaciones no previstas, eso me queda claro, pero,

¿No hay nada que hacer al respecto? ó ¿Debo conformarme con la frase "NOBODY IS PERFECT"?



Saludos

Si que existe una "teoría" que te aporta material que conduce a un buen diseño: las formas normales, que se aplican en normalización de base de datos. Cosa que si expresé. El llevar el diseño de una base de datos a la 3FN (3ra Forma Normal) en el 90% de los casos basta y no se necesita ir por más (para ciertos autores se reconocen incluso 7 formas normales, otros hablan de las 5 tradicionales).

Aplicando las formas normales se consigue una base de datos que elimina las redundancias o ambiguedades, organiza las tablas con los atributos de forma que se mantenga y respete el álgebra relacional, reduce (y hasta los elimina) los duplicados.

Pero es fundamental también señalar que en ocasiones, para bases de datos pesadas que cuentan con muchos registros y dispone de demasiadas tablas de movimiento, histórico, resumenes estadísticos, etc el seguir las reglas conduce a un diseño que compite contra el rendimiento y la posibilidad de acelerar ciertos cálculos y elaboración de informes por medio de consultas con cierta complejidad. En estos escenarios es mejor optar por ir en contra de la corriente y aplicar la denormalización en ciertas áreas una vez que se haya "estabilizado" las restantes por normalización.

Fuera de esto, hasta donde llegan mis conocimientos, no conozco otra "teoría" que aporte más material. El diseño de una base de datos nace por la capacidad del desarrollador, luego está en uno en si tomar las reglas normales o no.

Por esto es que se pueden esperar diferentes propuestas para un mismo contexto. Es lo que hace tan difícil dar cátedra de Base de Datos y en como calificar los trabajos prácticos que dan los profesores. Te podría dar charla de algunas de las discusiones y propuestas que tuve en mis cátedras de base de datos.

Cuando uno diseña sus DB hace un examen crítico de que parte delegar al motor y que al sistema. Es un debate eterno, que junto con la mezcla de experiencia, necesidades, y ciertas consideraciones técnicas-operativas impuestas por las propias restricciones del contexto y del motor elegido llevará a tomar ciertas decisiones.

Saludos,

[Delphius]

¿ Nos puedes ilustrar como se normaliza un base de datos ? Digo, ese es el punto medular de éste hilo, compartir con los demás nuestras experiencias, si no pensaramos así DelphiAccess no tendría razón de ser, es un asunto de colectivo.

Saludos

No soy Felipe.mx amigo, y si bien tengo las cosas en mi cabeza... si hay algo que no logro como explicarlo es el tema de la normalización. No me explico como es que lo hago... yo lo tengo incorporado como algo mecánico en mi cabeza, pero si tengo que buscarle palabras ya me trabo.
Puedes ver algo de eso en algunos hilos donde hice llegar algunas propuestas de base de datos. Como aquí.

Es muy raro en como encaro el diseño de la base de datos... es como si de la nada ya me saliera normales. Pienso en las entidades, sus relaciones y allí nomás en seco ataco con la regla normal.

Saludos,

[genriquez]

Si interpreto bien a Egostar, sería interesante es mostrar cómo enfrentamos algunos casos para tener mayor claridad en cuando normalizar y cuando no, porque a mi me pasa lo mismo, la normalización ya se hace "normal" con la experiencia, pero a la hora de explicarlo cuesta trabajo y definir los criterios de desnormalización (o denormalización ) no es fácil.

Saludos.

[Delphius]

Si interpreto bien a Egostar, sería interesante es mostrar cómo enfrentamos algunos casos para tener mayor claridad en cuando normalizar y cuando no, porque a mi me pasa lo mismo, la normalización ya se hace "normal" con la experiencia, pero a la hora de explicarlo cuesta trabajo y definir los criterios de desnormalización (o denormalización ) no es fácil.

Saludos.

Eso es justo lo que me pasa a mi. Veo las entidades, su relación y allí nomás como por magia, y de forma mecánica/automática e inconscientemente lo normalizo. Es decir no pienso, lo hago por instinto.
Pero en cuanto intento encontrar la forma de hacerlo, se me cruzan los cables. Es muy raro.

AGREGO:
Lo que al menos si puedo puntualizar es en como determinar las posibles relaciones que se pueden esperar entre las tablas. Con entender cuando una relación indica (1:1), (1:M), (M:M) y que hacer en cada caso se está llevando la mitad del diseño a escala normal.
Sale tuto... ya mismo escribo sobre el tema y le dedico un hilo propio.

Saludos,