database - nomenclatura - a la hora de diseñar una base de datos una buena costumbre para nombrar las tablas es usar los

Convención de nomenclatura de tablas relacionales (5)

Los plurales no son malos, siempre y cuando se usen de manera consistente, pero mi preferencia es singular.

Prescindiría de los guiones bajos a menos que desee esbozar una relación de muchos a muchos; y use un capital inicial porque ayuda a distinguir las cosas en los ORM.

Pero hay muchas convenciones de nomenclatura, por lo tanto, si desea usar guiones bajos, eso estará bien, siempre y cuando se haga de manera consistente.

Asi que:

User UserProduct (it is a users products after all)

Si solo un usuario puede tener cualquier producto, entonces

UserProductDescription

Pero si el producto es compartido por los usuarios:

ProductDescription

Si guarda sus guiones bajos para relaciones de muchos a muchos, puede hacer algo como:

UserProduct_Stuff

para formar un M-to-M entre UserProduct y Stuff, no estoy seguro de la pregunta sobre la naturaleza exacta de muchos a muchos necesarios.

Estoy comenzando un nuevo proyecto y me gustaría obtener mis nombres de tabla y columna desde el principio. Por ejemplo, siempre he usado el plural en los nombres de tabla, pero recientemente he aprendido que el singular es correcto.

Entonces, si obtuve una tabla de "usuario" y luego obtuve productos que solo el usuario tendrá, ¿debería llamarse la tabla "producto_usuario" o simplemente "producto"? Esta es una relación de uno a muchos.

Y más adelante, si tuviera (por algún motivo) varias descripciones de productos para cada producto, ¿sería "descripción_producto_usuario" o "descripción_producto" o simplemente "descripción"? Por supuesto, con las claves foráneas correctas establecidas. Nombrar solo la descripción sería problemático ya que también podría tener la descripción del usuario o la descripción de la cuenta o lo que sea ..

¿Qué tal si quiero una tabla relacional pura (de muchas a muchas) con solo dos columnas, cómo sería esto? "user_stuff" o tal vez algo así como "rel_user_stuff"? Y si es el primero, ¿de qué lo distinguiría, por ejemplo, "user_product"?

Cualquier ayuda es muy apreciada y si existe algún tipo de norma de convención de nombres que ustedes mismos recomienden, siéntanse libres de vincular.

Gracias

No hay ''correcto'' sobre singular vs plural - es principalmente una cuestión de gusto.

Depende en parte de tu enfoque. Si piensas en la tabla como una unidad, contiene ''plurales'' (porque contiene muchas filas, por lo que un nombre plural es apropiado). Si considera que el nombre de la tabla identifica una fila en una tabla, preferirá ''singular''. Esto significa que se considerará que su SQL está trabajando en una fila de la tabla. Está bien, aunque suele ser una simplificación excesiva; SQL funciona en conjuntos (más o menos). Sin embargo, podemos ir con singular para las respuestas a esta pregunta.

Dado que probablemente necesite una tabla ''usuario'', otro ''producto'' y la tercera para conectar a los usuarios con los productos, entonces necesita una tabla ''usuario_producto''.
Dado que la descripción se aplica a un producto, usaría ''product_description''. A menos que cada usuario nombre cada producto por sí mismo ...
La tabla ''user_product'' es (o podría ser) un ejemplo de una tabla con una ID de producto y una ID de usuario, y no mucho más. Usted nombra las tablas de dos atributos de la misma manera general: ''user_stuff''. Los prefijos decorativos como ''rel_'' realmente no ayudan. Verá algunas personas que usan ''t_'' delante de cada nombre de tabla, por ejemplo. Eso no es mucha ayuda.

No hay más correcto para usar singular que plural, ¿dónde has oído eso? Prefiero decir que la forma plural es más común para nombrar tablas de bases de datos ... y en mi opinión también más lógica. La tabla más a menudo contiene más de una fila;) En un modelo conceptual, aunque los nombres de las entidades a menudo están en singular.

Acerca de su pregunta, si ''Producto'' y ''Descripción del producto'' son conceptos con una identidad (es decir, entidades) en su modelo, simplemente llamaría a las tablas ''Productos'' y ''Descripción del producto''. Para las tablas que se usan para implementar una relación de muchos a muchos, suelo usar la convención de nomenclatura "SideA2SideB", por ejemplo, "Student2Course".

Singular vs. Plural: elija uno y quédese con él.

Las columnas no deben estar prefijadas / sufijadas / infijadas o de cualquier manera corregidas con referencias al hecho de que se trata de una columna. Lo mismo ocurre con las tablas. No nombre las tablas EMPLOYEE_T o TBL_EMPLOYEES porque en el segundo se reemplaza por una vista, las cosas se vuelven realmente confusas.

No incruste información de tipo en nombres, como "vc_firstname" para varchar o "flavour_enum". Tampoco incruste restricciones en los nombres de las columnas, como "department_fk" o "employee_pk".

En realidad, lo único bueno de * las correcciones que puedo pensar es que puedes usar palabras reservadas como where_t , tbl_order , user_vw . Por supuesto, en esos ejemplos, usar el plural habría resuelto el problema :)

No nombre todas las claves "ID". Las claves que se refieren a la misma cosa, deben tener el mismo nombre en todas las tablas. La columna de ID de usuario podría llamarse USER_ID en la tabla de usuario y todas las tablas que hacen referencia al usuario. La única vez que se renombra es cuando diferentes usuarios juegan diferentes roles, como Mensaje (sender_user_id, receiver_user_id). Esto realmente ayuda cuando se trata de consultas más grandes.

En cuanto a CaSe:

thisiswhatithinkofalllowercapscolumnnames. ALLUPPERCAPSISNOTBETTERBECAUSEITFEELSLIKESOMEONEISSCREAMINGATME. CamelCaseIsMarginallyBetterButItStillTakesTimeToParse. i_recommend_sticking_with_lower_case_and_underscore

En general, es mejor denominar "tablas de asignación" para que coincida con la relación que describe en lugar de los nombres de las tablas a las que se hace referencia. Un usuario puede tener cualquier cantidad de relaciones con los productos: user_likes_product , user_bought_product , user_wants_to_buy_product .

Nombre de la tabla

recientemente aprendido el singular es correcto

Sí. Cuidado con los paganos. Los nombres plurales en las tablas son una señal segura de alguien que no ha leído ninguno de los materiales estándar y no tiene conocimiento de la teoría de bases de datos.

Algunas de las cosas maravillosas sobre los estándares son: están todos integrados entre sí; trabajan juntos; y fueron escritos por mentes más grandes que las nuestras, por lo que no tenemos que debatirlas. El nombre de la tabla estándar se refiere a cada fila de la tabla, que se utiliza en la verborrea completa, no en el contenido total de la tabla (sabemos que la tabla Customer contiene todos los Clientes).

Relación, Frase Verbal

En las bases de datos relacionales genuinas que se han modelado (a diferencia de los sistemas de archivo de registro implementados en un contenedor de base de datos SQL):

las tablas son los Sujetos de la base de datos, por lo que son sustantivos , nuevamente, singulares
las relaciones entre las tablas son las Acciones que tienen lugar entre los sustantivos, por lo tanto, son verbos (es decir, no están numerados o nombrados arbitrariamente)
ese es el Predicado
todo lo que se puede leer directamente del modelo de datos (consulte mis ejemplos al final)
(el Predicado para una tabla independiente (el padre superior en una jerarquía) es que es independiente)
por lo tanto, la Frase Verbal es cuidadosamente elegida, de modo que es la más significativa, y se evitan los términos genéricos (esto se vuelve más fácil con la experiencia). La frase verbal es importante durante el modelado porque ayuda a resolver el modelo, es decir. aclarar relaciones, identificar errores y corregir los nombres de la tabla.

Diagram_A

Por supuesto, la relación se implementa en SQL como Restricción de clave externa en la tabla secundaria (más, más adelante). Aquí está la Frase de Verbos (en el modelo), el Predicado que representa (para ser leído del modelo) y el Nombre de Restricción de FK:

Initiates Each Customer Initiates 0-to-n SalesOrders Customer_Initiates_SalesOrder_fk

Tabla • Idioma

Sin embargo, al describir la tabla, particularmente en lenguaje técnico como los Predicados, u otra documentación, use singular y plurales como naturalmente en el idioma inglés. Teniendo en cuenta que la tabla se llama para la fila única (relación) y el lenguaje se refiere a cada fila derivada (relación derivada):

Each Customer initiates zero-to-many SalesOrders

Customers have zero-to-many SalesOrders

Entonces, si obtuve una tabla de "usuario" y luego obtuve productos que solo el usuario tendrá, ¿se debería llamar a la tabla "producto-usuario" o solo "producto"? Esta es una relación de uno a muchos.

(Esa no es una pregunta de convención de nomenclatura; esa es una pregunta de diseño de db). No importa si user::product es 1 :: n. Lo que importa es si el product es una entidad separada y si es una tabla independiente , es decir. puede existir por sí mismo. Por lo tanto, product , no user_product .

Y si el product existe solo en el contexto de un user , es decir. es una tabla dependiente , por user_product tanto user_product .

Diagram_B

Y más adelante, si tuviera (por alguna razón) varias descripciones de producto para cada producto, ¿sería "descripción del producto del usuario" o "descripción del producto" o simplemente "descripción"? Por supuesto, con las claves foráneas correctas establecidas. Nombrar solo la descripción sería problemático ya que también podría tener una descripción del usuario o descripción de la cuenta o lo que sea.

Está bien. O bien user_product_description xor product_description será correcto, en base a lo anterior. No es para diferenciarlo de otras xxxx_descriptions , sino para dar al nombre un sentido de dónde pertenece, siendo el prefijo la tabla padre.

¿Qué tal si quiero una tabla relacional pura (de muchas a muchas) con solo dos columnas, cómo sería esto? "cosas de usuario" o tal vez algo así como "rel-user-stuff"? Y si es el primero, ¿de qué lo distinguiría, por ejemplo, "producto-usuario"?

Esperemos que todas las tablas en la base de datos relacional sean tablas puramente relacionales y normalizadas. No es necesario identificarlo en el nombre (de lo contrario, todas las tablas serán rel_something ).
Si contiene solo los PK de los dos progenitores (lo que resuelve la relación lógica n :: n que no existe como entidad en el nivel lógico, en una tabla física ), es una tabla asociativa . Sí, normalmente el nombre es una combinación de los dos nombres de tablas principales.
- Tenga en cuenta que estos casos se aplican a la Frase Verbal, y se leen como, de padres a padres, ignorando la tabla hija, porque su único propósito en la vida es relacionar a los dos padres.
  Diagram_C
- Si no es una tabla asociativa (es decir, además de las dos PK, contiene datos), asígnele un nombre apropiado, y las frases verbales se aplican a ella, no al padre al final de la relación.
  Diagram_D
Si termina con dos tablas user_product , entonces es una señal muy fuerte de que no ha normalizado los datos. Así que retroceda unos pocos pasos y hágalo, y nombre las tablas de forma precisa y consistente. Los nombres se resolverán solos.

Convenio de denominación

Cualquier ayuda es muy apreciada y si existe algún tipo de norma de convención de nombres que ustedes mismos recomienden, siéntanse libres de vincular.

Lo que estás haciendo es muy importante y afectará la facilidad de uso y comprensión en todos los niveles. Por lo tanto, es bueno obtener la mayor comprensión posible desde el principio. La relevancia de la mayoría de esto no estará clara hasta que empiece a codificar en SQL.

Case es el primer elemento a tratar. Todas las tapas son inaceptables. El caso mixto es normal, especialmente si los usuarios tienen acceso directo a las tablas. Consulte mis modelos de datos. Tenga en cuenta que cuando el buscador utiliza un NonSQL demente, que tiene solo minúsculas, se lo doy, en cuyo caso incluyo guiones bajos (según sus ejemplos).
Mantenga un foco de datos , no una aplicación o enfoque de uso. Es, después de todo 2011, hemos tenido una arquitectura abierta desde 1984, y se supone que las bases de datos son independientes de las aplicaciones que las usan.
De esa manera, a medida que crecen, y más de lo que una aplicación los usa, la denominación seguirá siendo significativa y no necesitará corrección. (Las bases de datos que están completamente integradas en una sola aplicación no son bases de datos). Nombra los elementos de datos solo como datos.
Sea muy considerado, y nombre tablas y columnas con mucha precisión . No use UpdatedDate si es un tipo de datos DATETIME , use UpdatedDtm . No use _description si contiene una dosificación.
Es importante ser coherente en toda la base de datos. No use NumProduct en un lugar para indicar el número de productos y ItemNo o ItemNum en otro lugar para indicar el número de artículos. Use NumSomething para números-de, y SomethingNo o SomethingId para identificadores, consistentemente.
No user_first_name un prefijo al nombre de la columna con un nombre de tabla o un código corto, como user_first_name . SQL ya proporciona el nombre de tabla como calificador:
table_name.column_name -- notice the dot
Excepciones:
- La primera excepción es para PK, necesitan un manejo especial porque los codifica en uniones, todo el tiempo, y desea que las teclas se destaquen de las columnas de datos. Siempre use user_id , never id .
  - Tenga en cuenta que este no es un nombre de tabla usado como prefijo, sino un nombre descriptivo apropiado para el componente de la clave: user_id es la columna que identifica a un usuario, no el id de la tabla de user .
    - (Excepto por supuesto en los sistemas de archivo de registros, donde los sustitutos acceden a los archivos y no hay claves relacionales, allí son una y la misma cosa).
  - Utilice siempre el mismo nombre exacto para la columna de clave donde sea que el PK sea transportado (migrado) como un FK.
  - Por lo tanto, la tabla user_product tendrá un user_id como componente de su PK (user_id, product_no) .
  - la relevancia de esto quedará clara cuando comience a codificar. En primer lugar, con una id en muchas tablas, es fácil mezclarse en la codificación SQL. En segundo lugar, cualquier otra persona que el codificador inicial no tiene idea de lo que estaba tratando de hacer. Ambos son fáciles de prevenir, si las columnas clave se tratan como arriba.
- La segunda excepción es cuando hay más de un FK que hace referencia a la misma tabla de tabla primaria, transportada en el niño. De acuerdo con el Modelo Relacional , use los Nombres de Función para diferenciar el significado o uso, ej. AssemblyCode y ComponentCode para dos PartCodes . Y en ese caso, no use el PartCode indiferenciado para uno de ellos. Se preciso.
  Diagram_E
Prefijo
Si tiene más de 100 tablas, prefija los nombres de la tabla con un Área temática:
REF_ para tablas de referencia
OE_ para el grupo de entrada de pedidos, etc.
Solo en el nivel físico, no en el lógico (desordena el modelo).
Sufijo
Nunca use sufijos en las tablas, y siempre use sufijos en todo lo demás. Eso significa que en el uso lógico y normal de la base de datos, no hay guiones bajos; pero en el aspecto administrativo, los guiones bajos se usan como un separador:
_V View (con el TableName principal al frente, por supuesto)
_fk Clave externa (el nombre de la restricción, no el nombre de la columna)
_cac Cache
_seg Segmento
_tr Transacción (proc o función almacenada)
_fn Función (no transaccional), etc.
El formato es la tabla o nombre de FK, un guión bajo y nombre de acción, un guión bajo y, finalmente, el sufijo.
Esto es realmente importante porque cuando el servidor le da un mensaje de error:
____ blah blah blah error on object_name
usted sabe exactamente qué objeto fue violado, y qué estaba tratando de hacer:
____ blah blah blah error on Customer_Add_tr
Foreign Keys (la restricción, no la columna). El mejor nombre para un FK es usar la Frase Verbal (menos el "cada" y la cardinalidad).
Customer_Initiates_SalesOrder_fk
Part_Comprises_Component_fk
Part_IsConsumedIn_Assembly_fk

Use la secuencia Parent_Child_fk , no Child_Parent_fk es porque (a) aparece en el orden correcto de ordenamiento cuando los está buscando y (b) siempre conocemos al niño involucrado, lo que estamos adivinando es qué padre. El mensaje de error es encantador:
____ Foreign key violation on Vendor_Offers_PartVendor_fk .
Eso funciona bien para las personas que se molestan en modelar sus datos, donde se han identificado las frases verbales. Por lo demás, los sistemas de archivo de registros, etc., usan Parent_Child_fk .
Los índices son especiales, por lo que tienen una convención de nomenclatura propia, compuesta por, en orden , cada posición de personaje del 1 al 3:
U Unique, o _ para no único
C agrupado, o _ para no agrupado
_ separador
Para el resto:
- Si la clave es una columna o unas pocas columnas:
  ____ ColumnNames
- Si la clave es más que unas pocas columnas:
  ____ PK Clave principal (según el modelo)
  ____ AK[*n*] Tecla alternativa (término IDEF1X)
Tenga en cuenta que el nombre de la tabla no es necesario en el nombre del índice, porque siempre aparece como table_name.index_name.
Entonces, cuando Customer.UC_CustomerId o Product.U__AK aparece en un mensaje de error, le dice algo significativo. Cuando miras los índices sobre una mesa, puedes diferenciarlos fácilmente.
Encuentre a alguien calificado y profesional y síguelos. Mire sus diseños y estudie las convenciones de nombres que usan. Hágales preguntas específicas sobre cualquier cosa que no entienda. Por el contrario, corre como el infierno de cualquiera que demuestre poco respeto por nombrar convenciones o normas. Aquí hay algunos para comenzar:
- Contienen ejemplos reales de todo lo anterior. Haga preguntas para nombrar preguntas en este hilo.
- Por supuesto, los modelos implementan varios otros estándares, más allá de las convenciones de nomenclatura; puede ignorarlos por ahora o no dude en hacer nuevas preguntas específicas.
- Son varias páginas cada una, el soporte de imágenes en línea en SO es para las aves, y no se cargan consistentemente en diferentes navegadores; entonces tendrá que hacer clic en los enlaces.
- Tenga en cuenta que los archivos PDF tienen navegación completa, por lo tanto, haga clic en los botones de cristal azul o en los objetos donde se identifica la expansión:
- Los lectores que no están familiarizados con el Estándar de modelado relacional pueden encontrar útil la notación IDEF1X .

Ingreso de pedidos e inventario con direcciones que cumplen con los estándares

Sistema de Bulletin entre oficinas simple para PHP / MyNonSQL

Monitoreo de sensor con capacidad temporal completa

Respuestas a las preguntas

^{Eso no puede ser razonablemente respondido en el espacio de comentarios.}

Larry Lustig:
... incluso el ejemplo más trivial muestra ...
Si un cliente tiene productos de cero a muchos y un producto tiene componentes de uno a muchos y un componente tiene proveedores de uno a muchos y un proveedor vende componentes de cero a muchos y un vendedor tiene clientes de uno a muchos ¿Cuáles son los nombres "naturales" de las tablas que contienen Clientes, Productos, Componentes y Proveedores?

Hay dos problemas principales en tu comentario:

Usted declara que su ejemplo es "el más trivial", sin embargo, es cualquier cosa menos eso. Con ese tipo de contradicción, no estoy seguro si habla en serio, si es técnicamente capaz.
Esa especulación "trivial" tiene varios errores de Normalización bruta (Diseño de DB).
- Hasta que los corrijas, son antinaturales y anormales, y no tienen ningún sentido. También podría nombrarlos abnormal_1, abnormal_2, etc.
- Usted tiene "proveedores" que no suministran nada; referencias circulares (ilegales e innecesarias); clientes que compran productos sin ningún instrumento comercial (como Factura o Pedido de venta) como base para la compra (o ¿los clientes "poseen" productos?); relaciones de muchos a muchos sin resolver; etc.
- Una vez que se normalice y se identifiquen las tablas requeridas, sus nombres se harán obvios. Naturalmente.

En cualquier caso, intentaré atender su consulta. Lo que significa que tendré que darle más sentido, sin saber lo que quieres decir, así que por favor ten paciencia conmigo. Los errores graves son demasiados para enumerar y, dada la especificación de repuesto, no estoy seguro de haberlos corregido todos.

Asumiré que si el producto está compuesto de componentes, entonces el producto es un conjunto y los componentes se usan en más de un ensamblaje.
Además, dado que "el proveedor vende componentes de cero a muchos", que no venden productos o ensamblajes, solo venden componentes.

Especulación vs modelo normalizado

En caso de que no lo sepa, la diferencia entre las esquinas cuadradas (Independiente) y las esquinas redondeadas (Dependiente) es significativa, consulte el enlace de Notación IDEF1X. Del mismo modo, las líneas continuas (Identificación) frente a las líneas discontinuas (No identificables).

... ¿cuáles son los nombres "naturales" de las tablas que contienen Clientes, Productos, Componentes y Proveedores?

Cliente
Producto
Componente (O, AssemblyComponent, para aquellos que se dan cuenta de que un hecho identifica al otro)
Proveedor

Ahora que he resuelto las tablas, no entiendo tu problema. Quizás puedas publicar una pregunta específica .

VoteCoffee:
¿Cómo maneja el escenario que Ronnis publicó en su ejemplo donde existen relaciones múltiples entre 2 tablas (user_likes_product, user_bought_product)? Puedo malinterpretar, pero esto parece dar como resultado nombres de tablas duplicados usando la convención que detallaste.

Suponiendo que no hay errores de normalización, el User likes Product es un predicado, no una tabla. No confundirlos Consulte mi respuesta, donde se relaciona con sujetos, verbos y predicados, y mi respuesta a Larry inmediatamente anterior.

Cada tabla contiene un conjunto de hechos (cada fila es un hecho), no predicados. Los predicados (o proposiciones) no son hechos, pueden o no ser ciertos.
- El modelo relacional se basa en el cálculo del predicado de primer orden (más comúnmente conocido como lógica de primer orden). Un predicado es una oración de una sola oración en inglés simple y preciso, que se evalúa como verdadera o falsa.
Una consulta es una prueba de un predicado (o un número de predicados, encadenados) que da como resultado verdadero (el hecho existe) o falso (el hecho no existe).
Por lo tanto, las tablas deben nombrarse, como se detalla en mi Respuesta (convenciones de nomenclatura), para la fila, el Hecho y los Predicados deben documentarse (por supuesto, es parte de la documentación de la base de datos), pero como una lista separada de Predicados .
Esto no es una sugerencia de que no son importantes. Ellos son muy importantes, pero no escribiré eso aquí.
Rápidamente, entonces. Dado que el Modelo Relacional se basa en FOL, se puede decir que toda la base de datos es un conjunto de declaraciones, un conjunto de Predicados. Pero (a) hay muchos tipos de Predicados, y (b) una tabla no representa un Predicado (es la implementación física de muchos Predicados, y de diferentes tipos de Predicados).
Por lo tanto, nombrar la tabla para "el" Predicado que "representa" es un concepto absurdo.
Los "teóricos" conocen solo unos pocos Predicados, no entienden que, dado que el RM se fundó en el FOL, toda la base de datos es un conjunto de Predicados y de diferentes tipos.
- Y, por supuesto, eligen los absurdos de los pocos que conocen: EXISTING_PERSON; PERSON_IS_CALLED. Si no fuera tan triste, sería hilarante.
- Tenga en cuenta también que el nombre de la tabla estándar o atómica (que nombra la fila) funciona de forma brillante para toda la verborrea (incluidos todos los Predicados adjuntos a la tabla). Por el contrario, el idiota nombre de "tabla representa predicado" no puede. Lo cual está bien para los "teóricos", que entienden muy poco acerca de los Predicados, pero lo contrario es lo contrario.
Los Predicados que son relevantes para el modelo de datos, se expresan en el modelo, son de dos tipos.
- El primer conjunto está en forma de diagrama, no de texto, la notación. Estos incluyen varios Existenciales; Restringido; y Descriptor (atributos) Predicados.
- Por supuesto, eso significa que solo aquellos que pueden "leer" un modelo de datos estándar pueden leer esos Predicados. Es por eso que los "teóricos", que están severamente paralizados por su mentalidad solo de texto, no pueden leer los modelos de datos, por qué se apegan a su mentalidad de texto anterior a 1984.
- El segundo conjunto son aquellos Predicados que forman relaciones entre los Hechos. Esta es la línea de relación. La Frase Verbal (detallada anteriormente) identifica el Predicado, la proposición, que se ha implementado (que se puede probar mediante consulta). Uno no puede ser más explícito que eso.
- Por lo tanto, para alguien que domina los modelos de datos estándar, todos los Predicados que son relevantes están documentados en el modelo. No necesitan una lista separada de Predicados (¡pero los usuarios sí!).
Aquí hay un Modelo de Datos , donde he enumerado los Predicados. He elegido ese ejemplo porque muestra los Predicados existenciales, etc., así como los de Relación, los únicos Predicados no enumerados son los Descriptores. Aquí, debido al nivel de aprendizaje del buscador, lo trato como un usuario.

Por lo tanto, el hecho de que haya más de una tabla hija entre dos tablas principales no es un problema, solo hay que nombrarlos como el Hecho Existencial en su contenido y normalizar los nombres.

Aquí entran en juego las reglas que di para las frases verbales para los nombres de las relaciones de las tablas asociativas. Aquí hay una discusión Predicado vs Tabla , que cubre todos los puntos mencionados, en resumen.

Para una buena descripción breve del uso correcto de los Predicados y cómo usarlos (que es un contexto bastante diferente al de responder a los comentarios aquí), visite esta respuesta y desplácese hacia abajo hasta la sección Predicado .

Charles Burns:
Por secuencia, quise decir el objeto de estilo de Oracle utilizado puramente para almacenar un número y el siguiente de acuerdo con alguna regla (por ejemplo, "agregar 1"). Dado que Oracle carece de tablas de identificación automática, mi uso típico es generar identificadores únicos para las PK de la tabla. INSERT INTO foo (id, somedata) VALUES (foo_s.nextval, "data" ...)

Ok, eso es lo que llamamos una tabla Key o NextKey. Nómbralo como tal. Si tiene SubjectAreas, use COM_NextKey para indicar que es común en la base de datos.

Por cierto, ese es un método muy pobre para generar claves. No es escalable en absoluto, pero luego con el rendimiento de Oracle, es probable que "esté bien". Además, indica que su base de datos está llena de sustitutos, no relacionales en esas áreas. Lo que significa un rendimiento extremadamente pobre y falta de integridad.