none
Modelo de Datos Campos descricpion RRS feed

  • Pregunta

  • Hola

    Me entregaron un modelo de datos.

    Tiene unas 10 tablas con campo id y campo descripcion, de esta forma:

    Tabla Ciudad

    id_ciudad

    descripcion

    Tabla_activo

    Id_activo

    descripcion

    Normalizado deberia ser:

    Tabla_Ciudad

    Id_Ciudad

    Ciudad o DescripcionCiudad

    Tabla_activo

    id_activo

    Activo o DescripcionActivo

    Mi duda es, si utilizo en algun otra tabla el campo activo, digamos para indicar si un campo esta activo Si/NO tendria problemas con la tabla activo en el campo activo donde quiero que vaya la descripcion no ?


    DBA SQL Server Santiago/Chile

    lunes, 9 de febrero de 2015 20:35

Respuestas

  • Hola,

    Las columnas se identifican por la tabla que la contiene, no tendrás problemas de ambigüedad.

    activo.Activo != OtraTabla.Activo.

    En lo personal, nosotros colocamos un prefijo a cada columna dependiendo de la tabla. Por ejemplo si tenemos el campo Activo tanto en la tabla Cliente como Proveedor los campos serían distintos por el prefijo: ClieActivo y ProvActivo.

    Si la solución propuesta atendió su consulta no olvide marcarla como respuesta.

    Willams Morales
    Arequipa - PERÚ
    • Editado Willams Morales lunes, 9 de febrero de 2015 20:54
    • Marcado como respuesta CMAPM lunes, 9 de febrero de 2015 22:59
    lunes, 9 de febrero de 2015 20:54

Todas las respuestas

  • Hola,

    Las columnas se identifican por la tabla que la contiene, no tendrás problemas de ambigüedad.

    activo.Activo != OtraTabla.Activo.

    En lo personal, nosotros colocamos un prefijo a cada columna dependiendo de la tabla. Por ejemplo si tenemos el campo Activo tanto en la tabla Cliente como Proveedor los campos serían distintos por el prefijo: ClieActivo y ProvActivo.

    Si la solución propuesta atendió su consulta no olvide marcarla como respuesta.

    Willams Morales
    Arequipa - PERÚ
    • Editado Willams Morales lunes, 9 de febrero de 2015 20:54
    • Marcado como respuesta CMAPM lunes, 9 de febrero de 2015 22:59
    lunes, 9 de febrero de 2015 20:54
  • No entiendo bien.  Habla de normalización, pero lo que veo es estandarización de nombres.  Recordemos que "normalización" en base de datos es el proceso de modelar una base de datos relacional que cumpla las reglas de al menos una forma normal, y hay 5 formas normales.

    Volviendo a su pregunta, parece que quiere estandarizar nombres de campos y parece que tiene una duda de si el nombre de un campo puede repetirse en tablas distintas.

    La respuesta es:  Sí, puede tener campos de igual nombre en tablas distintas.  Si llega a unir las tablas en una consulta, deberá preceder el nombre del campo con el nombre o alias de tabla a la cual pertenece.  Eso es todo.

    En lo personal todas mis tablas tienen el nombre ID para el campo ID.  Si es tabla Ciudad, para mí es redundante tener Ciudad.IDCiudad.  Además me facilita grandemente la programación si todas las tablas tienen un campo llamado igual.

    Si lo que he escrito no apunta a lo que usted ha preguntado, entonces le agradeceré una aclaración.


    Jose R. MCP
    Code Samples

    • Marcado como respuesta CMAPM lunes, 9 de febrero de 2015 22:59
    • Desmarcado como respuesta CMAPM martes, 10 de febrero de 2015 1:57
    lunes, 9 de febrero de 2015 20:54
  • Si, tienes razón Jose.

    Es estandarizar nombres de campos.

    Mi tema de llamar por ejemplo ID en todas las tablas que la contengan es el siguiente:

    Tabla1, Tabla2,Tabla3

    En todas ellas tendria ID,Descripcion.

    Entonces en Tabla4:

    ID

    Descripcion

    Como hago para indicarle a la tabla4 que contiene FK de tabla1,tabla2 y tabl3 ?

    Yo hasta el dia de hoy lo hago indicandole no solo el ID en cada tabla le llamo Id_NombreTabla, de esta manera en tabla4 podré tener las 3 FK antes mencionada.

    Tabla4

    Id_Tabla4

    Descripcion

    Id_Tabla1

    Id_Tabla2

    Id_Tabla3

    Atento a sus comentarios.


    DBA SQL Server Santiago/Chile

    lunes, 9 de febrero de 2015 23:03
  • Hola,

    Lo que tu intentas hacer es definir estándares, convenciones, nomenclaturas para nombrar las columnas de tus tablas, en este caso las primary key y las foreign key. No existe una regla definitiva para hacerlo, la convención sirve si eso ayuda a tu proyecto y si todo tu equipo de trabajo está de acuerdo en ello, lo practica y lo respeta.

    Si tu opción (que me parece buena) es acompañar al prefijo Id el nombre de la tabla base, es correcto.

    lunes, 9 de febrero de 2015 23:14
  • Gracias William, seguire por dicho camino.

    Por otra parte:

    En teoria si llamara a todos las columnas ID de varias tablas, técnicamente no podría incluir cada una de ellas en una tabla como FK, asi como la muestro en el ejemplo.


    DBA SQL Server Santiago/Chile

    martes, 10 de febrero de 2015 0:30
  • Hola,

    Los nombres de columna de cada tabla deben de ser únicos, no se pueden especificar más de una vez. Lo anterior sería el mensaje que obtendrás si intentas tener más de una columna con el mismo nombre, en todo caso, ¿por qué no lo pruebas por ti mismo?

    create table CamposRepetidos (
    	id_CamposRepetidos int,
    	id int,
    	id int)

    Ahora, imagínate que tienes 3 tablas, la cuarta referencia a las 2 tablas anteriores:

    Create Table Tabla1 (
      id int, desc nvarchar(100))
    
    Create Table Tabla2 (
      id int, desc nvarchar(100))
    
    Create Table Tabla3 (
      id int, 
      id_Table1 int references Tabla1 (id),
      id_Table2 int references Tabla2 (id),
      desc nvarchar(100))
    
    

    Como verás, en la tabla Tabla3 no puedes tener la columna id para las 2 tablas que referencias porque tendrías mas de una columna con el mismo nombre y eso no es correcto. En todo caso son convenciones que cada equipo tiene, yo personalmente hubiese hecho:

    Create Table Tabla1 (
      idTabla1 int, desc nvarchar(100))
    
    Create Table Tabla2 (
      idTabla2 int, desc nvarchar(100))
    
    Create Table Tabla3 (
      idTabla3 int, 
      idTabla1 int references Tabla1 (idTabla1),
      idTabla2 int references Tabla2 (idTabla2),
      desc nvarchar(100))
    

    martes, 10 de febrero de 2015 1:31
  • Exactamente, ese fue mi ejemplo y por eso dije que "técnicamente no podría incluir cada una de ellas en una tabla"

    Y por eso quise comentar a lo que dijo WebJose "En lo personal todas mis tablas tienen el nombre ID para el campo ID"  y quise redundar en que NO se podia y di el ejemplo del porque NO se podia.



    DBA SQL Server Santiago/Chile

    martes, 10 de febrero de 2015 1:57
  • Hola,

    Jose mencionó que como convención a todas las columnas que identifica a una tabla de manera univoca las nombra como id, y eso es válido, lo que no significa que lleguen con el mismo nombre a las tablas con las que se relaciona, es probable que cuando se trate de una relación nombre de manera distinta al campo, en todo caso esperemos que el propio Jose nos comente como resuelve esa salvedad.


    martes, 10 de febrero de 2015 3:29
  • Ok, les aclaro:

    Todas mis tablas tienen una clave primaria.  Todas mis claves primarias, por experiencia, son autonuméricas.  Dichos campos autonuméricos siempre se llaman ID, independientemente de la tabla a la que pertenecen.   ¿Hasta ahí bien?

    Si tabla B necesita un FK a tabla A, entonces tabla B tendrá un nombre de la forma XXID ("ID" como sufijo porque siempre me ha tocado trabajos donde todo se trabaja en inglés), donde XX es una palabra representativa de la tabla a la cual apunta.

    Ejemplo:  Tabla A = tblCustomers; tabla B = tblInvoices.  La tabla A representa clientes; la B representa facturas (ventas).  Las ventas se ligan al cliente que las compra, ¿cierto?  Lo lógico es tener en tblInvoices un FK que apunte a un registro en la tabla tblCustomers para así identificar al cliente.  Entonces tengo la clave primaria tblCustomers.ID y la clave foránea tblInvoices.CustomerID.  ¿Ven lo bonito de este sistema de nomenclatura?  Al menos eso me parece a mí. :-)

    Y lo más lindo es cuando escribo código.  Para empezar nunca tengo que recordar cómo llamé la clave primaria de alguna tabla.  Siempre sé que es ID, entonces cuando escribo el T-SQL para crear una tabla ni siquiera tengo que verificar el nombre de clave primaria y simplemente escribo CustomerID int Not Null Constraint dbo_tblInvoices_CustomerMustExist Foreign Key References dbo.tblCustomers(ID).  Todo eso lo escribo mecánicamente.  Hasta podría crear alguna forma de macros para ni siquiera tener que digitar.  No he llegado a ese extremo de pereza, eso sí, jeje. :D

    Finalmente, como yo no uso ORM's, todo lo escribo usando ADO.net.  Que todas las claves primarias se llamen ID me ahorra bastante código en .net, empezando por las definiciones de nombres de columna y terminando con las propiedades en mis entidades.

    Ah, y les dejo un detallito.  ¿Ven el nombre del FOREIGN KEY en el ejemplo que digité?  Cuando uno trata de modificar datos y dicha modificación falla debido a una violación de un constraint, el nombre del constraint siempre aparece en el mensaje de error (SqlException).  Si bien es cierto que puedo usar el número de error para identificar un problema específico en el catch de un try..catch, que el nombre del FK contenga las palabras "MustExist" me ayuda cuando estoy depurando.  Si veo que el mensaje de error tiene un nombre de constraint con MustExist inmediatamente sé qué sucede.


    Jose R. MCP
    Code Samples


    • Editado webJose martes, 10 de febrero de 2015 6:08
    martes, 10 de febrero de 2015 6:05
  • Jose,

    Interesante compartir las experiencias incluso a este detalle, en lo personal, sobre el uso que haces del sufijo "MustExists" para notar un constraint foreign key yo sigo la convención que propone Microsoft para nombrar los constraints

    • PK_Cust_CustId: Primary Key
    • FK_Invo_CustId: Foreign Key
    • AK_Cust_CustCodigo: Unique
    • CK_Cust_CustEdad: Check

    Por el prefijo puedo darme cuenta del tipo de restricción, pero vale, como dije en comentarios anteriores, las convenciones son creadas para sentirnos cómodos y cada quién regula el asiento como mejor le queda para no sentir cansancio en las largas horas de desarrollo. En la definición de convenciones mientras todo el equipo decida y respete hablar el mismo idioma pienso que todo está bien.


    martes, 10 de febrero de 2015 6:26
  • Adendum al asunto de nomenclaturas de constraints:  Yo agrego una C al índice clustered porque así puedo darme cuenta fácilmente si un plan de ejecución usa o no usa el índice clustered, que es potencialmente el más rápido porque no tiene que referenciar bookmarks.  Ejemplos:

    ID int Not Null Constraint PKC_dbo_tblCustomers Primary Key Clustered

    O bien:

    , Constraint UXC_dbo_tblCustomers_SomeUniqueCombo Unique Clusterd (CampoA, CampoB)

    Ah, y viera que yo opté por un nombre "semi legible" en caso de que el error llegara a la interfase gráfica y un usuario no técnico tuviera que leerme algo.


    Jose R. MCP
    Code Samples



    • Editado webJose martes, 10 de febrero de 2015 13:36
    martes, 10 de febrero de 2015 13:33
  • José,

    Quizá esto suene trivial pero me está sirviendo de mucho las convenciones que usted adopta y por ahí ya empiezo a adoptar algunas que me parecen interesantes como el uso de la C para identificar que es una columna con índice clustered.

    Presiento que cuando hace combinaciones (join's) usted no trabaja con alias para las tablas, entiendo que usted nombra las tablas. Algo como

    select
      *
    from
      Tabla1
      inner join Tabla2 on (Tabla2.Tabla1ID = Tabla1.ID)

    ¿Pero como maneja las situaciones donde deberá volver a utilizar la misma tabla?

    select
      Venta.Fecha,
      Venta.Entrega,
      Documento.Tipo, /*documento venta ??*/
      Documento.Tipo /*documento entrega ??*/
    from
      Venta
      inner join Entrega on (Entrega.VentaID = Venta.ID)
      inner join Documento on (Documento.ID = Venta.TipoDocumento)
      inner join Documento on (Documento.ID = Entrega.TipoDocumento)

    Si quiero mostrar en el select el tipo de documento por la venta y también el tipo de documento por la entrega, ¿en estos casos hace uso de algún ALIAS especial para discriminar las tablas sólo para estos casos? 


    martes, 10 de febrero de 2015 16:45
  • Pues presiente mal, jeje.  Sí uso Alias en todos mis Join, y los uso para acortar nombres.  El detalle es que yo suelo crear Views que me escudan de cualquier mala convención que pueda yo tener en los JOIN's, jeje.

    Lo que dejé de hacer es usar nombres de una o dos letras en los CTE's porque a veces necesito saber qué significaban.  Entonces ahora uso nombres descriptivos para CTE's y si los uso en FROM's con más de una tabla, entonces les pongo un alias.

    En fin, si conoce de alguna convención para alias de tablas en consultas, me gustaría escucharlo.


    Jose R. MCP
    Code Samples

    martes, 10 de febrero de 2015 16:53
  • Hola,

    Bueno yo en mis inicios cuando trabajaba de practicante me "obligaban" a definir los alias empezando por la A hasta la Z. Ya viere usted que si las combinaciones entre tablas (join's) eran bastantes entonces los alias se inicializaban con AA, BB, esto ya parecía las columnas de Excel. Es por demás claro que esos alias no aportan para nada en la descripción de la tabla.

    Luego en el tiempo pensé que es una buena idea otorgar prefijos a las columnas de una tabla, prefijos de sólo 4 caracteres. Por ejemplo la tabla Cliente (ClieId, ClieNombre); DireccionesCliente (DirCId, DirCDireccion), de esa forma sólo por el nombre de la columna podía saber a que tabla pertenecía o por lo menos tenía la sospecha jeje.

    Finalmente adopte la decisión de que los alias de las tablas sean esos prefijos, pero el problema persistía cuando en la combinación de tablas estaba más de una vez una tabla, así que termine colocando un número secuancial como sufijo al prefijo, algo como 

    Cliente Clie1
    inner join DireccionesCliente DirC1 on (DirC1.ClieId = Clie1.ClieId)

    Aún no logro tener una convención que me "convenza"


    martes, 10 de febrero de 2015 18:06