¿Convenciones de Nomenclatura de Bases de Datos, Tablas y Columnas? [cerrado]

Respuesta tardía aquí, pero en resumen:

1. Mi preferencia es plural
2. Sí
3. Tablas: *Usualmente* sin prefijos es mejor. Columnas : No.
4. Tablas y columnas: PascalCase.

Elaboración:

(1) Lo que debes hacer. Hay muy pocas cosas que usted debe hacer de cierta manera, cada vez, pero hay unas pocas.

• Nombra tus claves primarias usando Formato" [singularOfTableName]ID". Es decir, si el nombre de la tabla es Customer o Customers , la clave principal debe ser CustomerID .
• Además, las claves foráneas deben denominarse consistentemente en tablas diferentes. Debería ser legal golpear a alguien que no hace esto. Yo diría que mientras que las restricciones de clave foránea definidas son a menudo importantes, la nomenclatura de clave foránea coherente es siempre importante
• Tu base de datos debe tener convenciones internas. Aunque en secciones posteriores me verás siendo muy flexible, dentro de un nombre de base de datos debe ser muy consistente . Si su tabla para clientes se llama Clientes o Cliente es menos importante que lo haga de la misma manera en la misma base de datos. Y puede lanzar una moneda para determinar cómo usar guiones bajos, pero luego debe seguir usándolos de la misma manera. Si no haces esto, eres un mal persona que debería tener baja autoestima.

(2) Lo que probablemente deberías hacer.

• Los campos que representan el mismo tipo de datos en diferentes tablas deben denominarse de la misma manera. No tienes Zip en una mesa y código postal en otra.
• Para separar las palabras en los nombres de las tablas o columnas, utilice PascalCasing. Usar camelCasing no sería intrínsecamente problemático, pero esa no es la convención y se vería divertido. Voy a abordar guiones bajos en un momento. (No puede usar ALLCAPS como en los viejos tiempos. DETESTABLE.ANNOYING_COLUMN estaba bien en DB2 hace 20 años, pero no ahora.)
• No acortar o abreviar palabras artificialmente. Es mejor que un nombre sea largo y claro que corto y confuso. Ultra-short names es un remanente de tiempos más oscuros y salvajes. Cus_AddRef. ¿Qué demonios es eso? ¿Referencia Del Destinatario de Custodia? Reembolso Adicional del Cliente? Referencia de Dirección Personalizada?

(3) Lo que debería considerarlo.

• Realmente creo que deberías tener nombres plurales para tablas; algunos piensan en singular. Lea los argumentos en otra parte. Sin embargo, los nombres de las columnas deben ser singulares. Incluso si utiliza nombres de tabla plurales, las tablas que representan combinaciones de otras tablas pueden estar en singular. Por ejemplo, si tienes una tabla Promotions y una tabla Items , una tabla que representa un artículo que forma parte de una promoción podría ser Promotions_Items, pero también podría legítimamente ser Promotion_Items creo (reflejando la relación uno-a-muchos).
• Utilice guiones bajos de manera consistente y para un propósito particular. Solo los nombres generales de las tablas deben ser lo suficientemente claros con PascalCasing; no necesita guiones bajos para separar palabras. Guarde guiones bajos (a) para indicar una tabla asociativa o (b) para prefijar, que abordaré en la siguiente viñeta.
• El prefijo no es ni bueno ni malo. normalmente no es lo mejor. En su primer db o dos, yo no sugeriría el uso de prefijos para la agrupación temática general de cuadros. Las tablas terminan no encajando fácilmente en sus categorías, y en realidad puede hacer que sea más difícil encontrar tablas. Con experiencia, puede planificar y aplicar un esquema de prefijo que hace más bien que mal. Trabajé en una db una vez donde las tablas de datos comenzaron con tbl , las tablas de configuración con ctbl , las vistas con vew , proc sp , y udf fn , y algunos otros; fue meticulosamente, aplicado consistentemente por lo que funcionó bien. La única vez que necesita prefijos es cuando tiene soluciones realmente separadas que por alguna razón residen en la misma bd; prefijarlas puede ser muy útil para agrupar las tablas. El prefijo también está bien para situaciones especiales, como para las tablas temporales que desea destacar.
• Muy raramente (si alguna vez) querrías para prefijar columnas.

Ok, ya que estamos sopesando con la opinión:

Creo que los nombres de las tablas deben ser plurales. Las tablas son una colección (una tabla) de entidades. Cada fila representa una sola entidad, y la tabla representa la colección. Así que yo llamaría a una tabla de Personas Entidades Personas (o Personas, lo que te apetezca).

Para aquellos que les gusta ver "nombres de entidad" singulares en las consultas, eso es para lo que usaría alias de tabla:

SELECT person.Name
FROM People person

Un poco como "de persona en persona" de LINQ seleccionar person.Name".

En cuanto a 2, 3 y 4, estoy de acuerdo con @Lars.

Trabajo en un equipo de soporte de base de datos con tres DBA y nuestras opciones consideradas son:

1. Cualquier estándar de nomenclatura es mejor que ningún estándar.
2. No hay un estándar "verdadero", todos tenemos nuestras preferencias
3. Si ya existe un estándar, utilícelo. No cree otro estándar o enturbie los estándares existentes.

Usamos nombres singulares para las tablas. Las tablas suelen ir precedidas por el nombre del sistema (o sus siglas). Esto es útil si el complejo del sistema, ya que puede cambiar el prefijo para agrupar las tablas de forma lógica (es decir. reg_customer, reg_booking y regadmin_limits).

Para los campos esperamos que los nombres de campo incluyan el prefijo/acryonm de la tabla (es decir, cust_address1) y también preferimos el uso de un conjunto estándar de sufijos ( _id para el PK, _cd para "código", _nm para "nombre", _nb para "número", _dt para "Fecha").

El nombre del campo clave Foriegn debe ser el mismo que el campo clave primaria.

I. e.

SELECT cust_nm, cust_add1, booking_dt
FROM reg_customer
INNER JOIN reg_booking
ON reg_customer.cust_id = reg_booking.cust_id

Al desarrollar un nuevo proyecto, le recomiendo que escriba todos los nombres de entidad preferidos, prefijos y acrónimos y entregue este documento a sus desarrolladores. Luego, cuando deciden crear una nueva tabla, pueden hacer referencia al documento en lugar de "adivinar" cómo deben llamarse la tabla y los campos.

1. No. Una tabla debe tener el nombre de la entidad que representa. Persona, no personas es como te referirías a quien sea que uno de los registros representa.
2. De nuevo, lo mismo. La columna FirstName realmente no debería llamarse FirstNames. Todo depende de lo que quieras representar con la columna.
3. NO.
4. Sí. Preséntalo para mayor claridad. Si necesita tener columnas como "FirstName", la carcasa hará que sea más fácil de leer.

Ok. Eso es mi $0.02

También estoy a favor de una convención de nomenclatura de estilo ISO/IEC 11179, señalando que son directrices en lugar de ser prescriptivas.

Ver Nombre del elemento de datos en Wikipedia :

"Las tablas son Colecciones de Entidades y siguen las pautas de nomenclatura de Colecciones. Idealmente, se utiliza un nombre colectivo: por ejemplo., Personal. Plural también es correcto: Empleados. Los nombres incorrectos incluyen: Empleado, tblEmployee, y EmployeeTable."

Como siempre, hay excepciones a las reglas, por ejemplo, una tabla que siempre tiene exactamente una fila puede ser mejor con un nombre singular, por ejemplo, una tabla de configuración. Y la consistencia es de suma importancia: verifique si su tienda tiene una convención y, si es así, sígala; si no le gusta, haga un caso comercial para cambiarlo en lugar de ser el llanero solitario.

Nuestra preferencia:

1. ¿Los nombres de las tablas deben ser plurales?
   Nunca. Los argumentos para que sea una colección tienen sentido, pero nunca se sabe lo que la tabla va a contener (0,1 o muchos elementos). Las reglas plurales hacen que el nombramiento sea innecesariamente complicado. 1 Casa, 2 casas, ratón vs ratones, persona vs personas, y ni siquiera hemos mirado en otros idiomas.

   Update person set property = 'value' actúa sobre cada persona en la mesa.
   Select * from person where person.name = 'Greg' devuelve una colección / rowset de persona filas.

2. ¿Los nombres de las columnas deben ser en singular?
   Por lo general, sí, excepto cuando se están rompiendo las reglas de normalización.

3. ¿Debo prefijar tablas o columnas?
   Sobre todo una preferencia de plataforma. Preferimos prefijar las columnas con el nombre de la tabla. No anteponemos las tablas, pero sí las vistas (v_) y stored_procedures (sp_ o f_ (function)). Eso ayuda a las personas que quieren tratar de upday v_person.edad que es en realidad un campo calculado en una vista (que no puede ser Actualizado de todos modos).

   También es una gran manera de evitar la colisión de palabras clave (entrega.from breaks, pero delivery_from no).

   Hace que el código sea más detallado, pero a menudo ayuda en la legibilidad.

   bob = new person()
bob.person_name = 'Bob'
bob.person_dob = '1958-12-21'
   ... es muy legible y explícito. Sin embargo, esto puede salirse de control:

   customer.customer_customer_type_id

   Indica una relación entre el cliente y la tabla customer_type, indica la clave principal en la tabla customer_type (customer_type_id) y si si alguna vez ves 'customer_customer_type_id' mientras depuras una consulta, sabrás instantáneamente de dónde proviene (tabla de clientes).

   O donde tiene una relación M-M entre customer_type y customer_category (solo ciertos tipos están disponibles para ciertas categorías)

   customer_category_customer_type_id

   ... es un poco (!) en el lado largo.

4. ¿Debo usar algún caso para nombrar elementos? Sí-minúsculas:), con guiones bajos. Estos son muy legibles y multiplataforma. Junto con 3 arriba también tiene sentido.

   Sin embargo, la mayoría de estas son preferencias. - Mientras seas consistente, debería ser predecible para cualquiera que tenga que leerlo.

Eche un vistazo a ISO 11179-5: Principios de denominación e identificación Puedes obtenerlo aquí: http://metadata-standards.org/11179/#11179-5

Escribí sobre ello un tiempo atrás aquí: Convenciones de nomenclatura ISO-11179

Escucho el argumento todo el tiempo de que si una tabla está o no pluralizada es todo una cuestión de gusto personal y no hay mejores prácticas. No creo que eso sea cierto, especialmente como programador en lugar de un DBA. Por lo que sé, no hay razones legítimas para pluralizar un nombre de tabla que no sea "Solo tiene sentido para mí porque es una colección de objetos", mientras que hay ganancias legítimas en el código al tener nombres de tabla singulares. Por ejemplo:

1. It evita errores y errores causados por ambigüedades plurales. Los programadores no son exactamente conocidos por su experiencia ortográfica, y pluralizar algunas palabras es confuso. Por ejemplo, ¿la palabra plural termina en ' es 'o solo 's'? ¿Son personas o personas? Cuando trabajas en un proyecto con equipos grandes, esto puede convertirse en un problema. Por ejemplo, una instancia en la que un miembro del equipo utiliza el método incorrecto para pluralizar una tabla que crea. En el momento en que interactúo con esta tabla, se usa en todo el código I no tienen acceso a o tomaría mucho tiempo para arreglar. El resultado es que tengo que recordar deletrear mal la mesa cada vez que la uso. Algo muy similar a esto me pasó. Cuanto más fácil sea que cada miembro del equipo use de manera consistente y fácil los nombres exactos y correctos de las tablas sin errores ni tener que buscar los nombres de las tablas todo el tiempo, mejor. La versión singular es mucho más fácil de manejar en un entorno de equipo.

2. Si utiliza la versión singular de un nombre de la tabla Y prefije la clave principal con el nombre de la tabla, ahora tiene la ventaja de determinar fácilmente un nombre de tabla a partir de una clave primaria o viceversa solo mediante código. Se le puede dar una variable con un nombre de tabla en ella, concatenar " Id " hasta el final, y ahora tiene la clave principal de la tabla a través de código, sin tener que hacer una consulta adicional. O puede cortar " Id " del final de una clave primaria para determinar un nombre de tabla a través de un código. Si utiliza " id " sin un nombre de tabla para el principal clave, entonces usted no puede a través de código determinar el nombre de la tabla de la clave principal. Además, la mayoría de las personas que pluralizan los nombres de tabla y anteponen las columnas PK con el nombre de la tabla usan la versión singular del nombre de la tabla en el PK (por ejemplo, statuses y StatusId), lo que hace imposible hacer esto en absoluto.

3. Si hace que los nombres de tabla sean singulares, puede hacer que coincidan con los nombres de clase que representan. Una vez más, esto puede simplificar el código y permitirle hacer cosas realmente ordenadas, como crear una instancia de una clase teniendo nada más que el nombre de la tabla. También solo hace que su código sea más consistente, lo que conduce a...

4. Si hace que el nombre de la tabla sea singular, hará que su esquema de nombres sea coherente, organizado y fácil de mantener en cada ubicación. Sabes que en cada instancia de tu código, ya sea en un nombre de columna, como un nombre de clase o como el nombre de la tabla, es exactamente el mismo nombre. Esto le permite realizar búsquedas globales para ver dónde se utilizan los datos. Cuando si pluraliza un nombre de tabla, habrá casos en los que utilizará la versión singular de ese nombre de tabla (la clase en la que se convierte, en la clave primaria). Simplemente tiene sentido no tener algunas instancias donde sus datos se conocen como plurales y algunas instancias en singular.

En resumen, si pluraliza los nombres de las tablas, está perdiendo todo tipo de ventajas al hacer que su código sea más inteligente y fácil de manejar. Incluso puede haber casos en los que tenga que buscar tablas / matrices para convertir los nombres de las tablas en nombres de objetos o códigos locales que podría haber evitado. Los nombres de tabla singulares, aunque tal vez se sientan un poco extraños al principio, ofrecen ventajas significativas sobre los nombres pluralizados y creo que son mejores prácticas.

Sé que esto es tarde para el juego, y la pregunta ya ha sido respondida muy bien, pero quiero ofrecer mi opinión sobre #3 con respecto al prefijo de los nombres de las columnas.

Todas las columnas deben ser nombradas con un prefijo que sea único para la tabla en la que están definidas.

Por ejemplo, dadas las tablas "cliente" y "dirección", vamos con los prefijos de "cust" y "addr", respectivamente. "el cliente" tendría "cust_id", "cust_name", etc. en ella. "dirección" tendría "addr_id", "addr_cust_id" (FK de vuelta al cliente), "addr_street", etc. en ella.

Cuando se me presentó por primera vez este estándar, estaba totalmente en contra; odiaba la idea. No podía soportar la idea de toda esa mecanografía extra y redundancia. Ahora he tenido suficiente experiencia con él que nunca volvería.

El resultado de hacer esto es que todas las columnas en su esquema de base de datos son únicas. Hay un beneficio importante en esto, que supera todos los argumentos en contra (en mi opinión, por supuesto):

Puede buscar toda su base de código y encontrar de manera confiable cada línea de código que toque una columna en particular.

El beneficio de #1 es increíblemente enorme. Puedo desaprobar una columna y saber exactamente qué archivos deben actualizarse antes de que la columna pueda eliminarse del esquema de forma segura. Puedo cambiar el significado de una columna y saber exactamente qué código necesita ser refactorizado. O simplemente puedo decir si los datos de una columna se están utilizando en una parte particular del sistema. No puedo contar el número de veces que esto ha convertido un proyecto potencialmente enorme en uno simple, ni la cantidad de horas que hemos ahorrado en el trabajo de desarrollo.

Otro beneficio relativamente menor es que solo tiene que usar alias de tabla cuando hace una unión automática:

SELECT cust_id, cust_name, addr_street, addr_city, addr_state
    FROM customer
        INNER JOIN address ON addr_cust_id = cust_id
    WHERE cust_name LIKE 'J%';

Mis opiniones al respecto son:

1) No, los nombres de las tablas deben ser singulares.

Mientras que parece tener sentido para la selección simple (select * from Orders) tiene menos sentido para el equivalente OO (Orders x = new Orders).

Una tabla en una BD es realmente el conjunto de esa entidad, tiene más sentido una vez que estás usando set-logic:

select Orders.*
from Orders inner join Products
    on Orders.Key = Products.Key

Esa última línea, la lógica real de la combinación, parece confusa con los nombres de tabla plurales.

No estoy seguro de usar siempre un alias (como sugiere Matt) aclara eso.

2) Deben ser singulares ya que solo tienen 1 propiedad

3) Nunca, si el nombre de la columna es ambiguo (como arriba, donde ambos tienen una columna llamada [Clave]), el nombre de la tabla (o su alias) puede distinguirlos lo suficientemente bien. Desea que las consultas sean rápidas de escribir y simples: los prefijos agregan complejidad innecesaria.

4) Lo que quieras, te sugiero CapitalCase

No creo que haya un conjunto de directrices absolutas sobre ninguno de estos.

Siempre y cuando lo que elijas sea consistente en toda la aplicación o base de datos, no creo que realmente importe.

En mi opinión:

1. Los nombres de las tablas deben ser plurales.
2. Los nombres de las columnas deben ser singulares.
3. No.
4. camelCase (mi preferido) o underscore_separated para ambos nombres de tabla y nombres de columna.

Sin embargo, como se ha mencionado, cualquier convención es mejor que ninguna convención. No importa cómo elija hacerlo, documéntelo para que las modificaciones futuras sigan las mismas convenciones.

1. Definitivamente mantener nombres de tabla singular, persona no personas
   1. Lo mismo aquí
   2. No. He visto algunos prefijos terribles, yendo tan lejos como para indicar lo que se trata de una tabla (tbl_) o un procedimiento de almacén de usuarios (usp_). Esto seguido por el nombre de la base de datos... No lo hagas!
   3. Sí. Tiendo a PascalCase todos mis nombres de tabla

Creo que la mejor respuesta a cada una de esas preguntas sería dada por usted y su equipo. Es mucho más importante tener una convención de nomenclatura que cómo es exactamente la convención de nomenclatura.

Como no hay una respuesta correcta a eso, deberías tomarte un tiempo (pero no demasiado) y elegir tus propias convenciones y - aquí está la parte importante - apégate a ella.

Por supuesto que es bueno buscar alguna información sobre los estándares en eso, que es lo que estás pidiendo, pero no ansioso o preocupado por la cantidad de respuestas diferentes que puede obtener: elija la que le parezca mejor.

Por si acaso, aquí están mis respuestas:

1. Sí. Una tabla es un grupo de registros, los maestros o actores, así... plural.
2. Sí.
3. No los uso.
4. La base de datos que uso más a menudo - Firebird - mantiene todo en mayúsculas, por lo que no importa. De todos modos, cuando estoy programando escribo los nombres de una manera que es más fácil de leer, como releaseYear.

Las convenciones de nomenclatura permiten al equipo de desarrollo diseñar la capacidad de descubrimiento y mantenimiento en el corazón del proyecto.

Una buena convención de nombres toma tiempo para evolucionar, pero una vez que está en su lugar, permite al equipo avanzar con un lenguaje común. Una buena convención de nombres crece orgánicamente con el proyecto. Una buena convención de nomenclatura hace frente fácilmente a los cambios durante la fase más larga e importante del ciclo de vida del software: la gestión de servicios en producción.

Aquí están mis respuestas:

1. Sí, los nombres de las tablas deben ser plurales cuando se refieren a un conjunto de operaciones , valores , o contrapartes, por ejemplo.
2. Sí.
3. Sí. Las tablas SQL tienen el prefijo tb_, las vistas tienen el prefijo vw_, los procedimientos almacenados tienen el prefijo usp_ y los disparadores tienen el prefijo tg_ seguido del nombre de la base de datos.
4. El nombre de la columna debe estar en minúsculas separadas por subrayado.

Nombrar es difícil, pero en cada organización hay alguien que puede nombrar cosas y en cada equipo de software debe haber alguien que asuma la responsabilidad de los estándares de nombres y se asegure de que los problemas de nombres como sec_id, sec_value y security_id se resuelven antes de que se incorporen al proyecto.

Entonces, ¿cuáles son los principios básicos de una buena convención de nomenclatura y estándares: -

• Utilice el lenguaje de su cliente y su dominio de solución
• Be descriptivo
• Ser coherente
• Desambiguar, reflejar y refactorizar
• No use abreviaturas a menos que son claros para todos
• No utilice las palabras clave reservadas SQL como nombres de columnas

Aquí hay un enlace que ofrece algunas opciones. Estaba buscando una especificación simple que pudiera seguir en lugar de tener que confiar en una parcialmente definida.

Http://justinsomnia.org/writings/naming_conventions.html

Los nombres de las tablas siempre deben ser singulares, porque representan un conjunto de objetos. Como usted dice rebaño para designar un grupo de ovejas, o rebaño designan un grupo de aves. No hay necesidad de plural. Cuando un nombre de tabla es la composición de dos nombres y la convención de nomenclatura está en plural, se hace difícil saber si el nombre plural debe ser la primera palabra o la segunda palabra o ambas. Es el objeto lógico.instancia, no objetos.instancia. O TableName.columna, no nombres de tabla.columna(s). Microsoft SQL no es el caso sensible, es más fácil leer los nombres de tabla, si se utilizan letras mayúsculas, para separar los nombres de tabla o columna cuando están compuestos por dos o más nombres.

Nombre de la tabla: Debe ser singular, ya que es una entidad singular que representa un objeto del mundo real y no objetos, que es singular.

Nombre de la columna: Debe ser singular solo entonces transmite que tendrá un valor atómico y confirmará a la teoría de la normalización. Sin embargo, si hay n número del mismo tipo de propiedades, entonces deben ser sufijados con 1, 2,..., n, etc.

Prefijando Tablas / Columnas: Es un tema enorme, discutiremos tarde.

Carcasa: Debería ser Camel case

Mi amigo, Patrick Karcher, le pido que por favor no escriba nada que pueda ser ofensivo para alguien, como usted escribió, "•Además, las claves foráneas deben ser nombradas consistentemente en tablas diferentes. Debería ser legal golpear a alguien que no hace esto.". Nunca he cometido este error mi amigo Patrick, pero estoy escribiendo en general. ¿Y si ellos juntos planean vencerte por esto? :)

Muy tarde a la fiesta, pero todavía quería agregar mis dos centavos sobre los prefijos de columna

Parece haber dos argumentos principales para usar el estándar de nomenclatura table_column (o TableColumn) para columnas, ambos basados en el hecho de que el nombre de la columna en sí será único en toda su base de datos:

1) No tiene que especificar nombres de tabla y/o alias de columna en sus consultas todo el tiempo

2) Puede buscar fácilmente todo el código para el nombre de la columna

I creo que ambos argumentos son defectuosos. La solución para ambos problemas sin usar prefijos es fácil. Aquí está mi propuesta:

Utilice siempre el nombre de la tabla en su SQL. Por ejemplo, utilice siempre la tabla.columna en lugar de columna.

Obviamente resuelve 2) ya que ahora solo puede buscar tabla.columna en lugar de table_column.

Pero puedo oírte gritar, ¿cómo se resuelve 1)? Se trataba exactamente de evitar esto. Sí, lo fue, pero la solución era horriblemente defectuosa. ¿Por qué? Bueno, el la solución de prefijo se reduce a:
Para evitar tener que especificar tabla.columna cuando hay ambigüedad, nombras todas tus columnas table_column!
Pero esto significa que a partir de ahora siempre tendrá que escribir el nombre de la columna cada vez que especifique una columna. Pero si tienes que hacer eso de todos modos, ¿cuál es el beneficio sobre la tabla de escritura siempre explícita.columna? Exactamente, no hay beneficio, es exactamente el mismo número de caracteres para escribir.

Editar: sí, soy consciente de que nombrar las columnas con el prefix impone el uso correcto mientras que mi enfoque se basa en los programadores

Convenciones de Nomenclatura de Bases de datos Esenciales (y Estilo) (haga clic aquí para una descripción más detallada)

Nombres de tablas elija nombres cortos e inequívocos, utilizando no más de una o dos palabras distinguir tablas fácilmente facilita la asignación de nombres de campos únicos, así como la búsqueda y la vinculación de tablas dar a las tablas nombres singulares, nunca plurales (actualización: todavía estoy de acuerdo con las razones dadas para esta convención, pero a la mayoría de la gente realmente le gustan los nombres de tablas plurales, así que he suavizado mi postura)... siga el enlace anterior por favor

SELECT 
   UserID, FirstName, MiddleInitial, LastName
FROM Users
ORDER BY LastName

Nombres de tabla singular. Digamos que estabas modelando una relación entre alguien y su dirección. Por ejemplo, si está leyendo un datamodel, preferiría "cada persona puede vivir en 0,1 o muchas direcciones.' o "cada pueblo puede vivir en 0,1 o muchas direcciones.' Creo que es más fácil pluralizar la dirección, en lugar de tener que reformular a la gente como persona. Además, los sustantivos colectivos son muy a menudo diferentes a la versión singular.

--Example SQL

CREATE TABLE D001_Students
(
    StudentID INTEGER CONSTRAINT nnD001_STID NOT NULL,
    ChristianName NVARCHAR(255) CONSTRAINT nnD001_CHNA NOT NULL,
    Surname NVARCHAR(255) CONSTRAINT nnD001_SURN NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(StudentID)
);

CREATE INDEX idxD001_STID on D001_Students;

CREATE TABLE D002_Classes
(
    ClassID INTEGER CONSTRAINT nnD002_CLID NOT NULL,
    StudentID INTEGER CONSTRAINT nnD002_STID NOT NULL,
    ClassName NVARCHAR(255) CONSTRAINT nnD002_CLNA NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(ClassID, StudentID),
    CONSTRAINT fkD001_STID FOREIGN KEY(StudentID) 
        REFERENCES D001_Students(StudentID)
);

CREATE INDEX idxD002_CLID on D002_Classes;

CREATE VIEW V001_StudentClasses
(
    SELECT
        D001.ChristianName,
        D001.Surname,
        D002.ClassName
    FROM
        D001_Students D001
            INNER JOIN
        D002_Classes D002
            ON
        D001.StudentID = D002.StudentID
);

Estas son las convenciones que me enseñaron, pero debes adaptarte a lo que sea que uses en tu desarrollo.

1. Plural. Es una colección de entidades.
2. Sí. El atributo es una representación de la propiedad singular de una entidad.
3. Sí, el nombre de la tabla de prefijo permite nombrar fácilmente todos los índices de restricciones y alias de tabla.
4. Pascal Case para nombres de tablas y columnas, prefijo + mayúsculas para índices y restricciones.