Registro de entrada y salida

Si lo que quieres es definir claves foráneas a ENTIDADES deberás de definir dos índices uno para entradas y otro para salidas (salvo que uno de estos campos esté en el primer lugar de la PORQUE lo cual ya no sería necesario un índice adicional).
Lo que tienes que tomar en cuenta serán los accesos que piensas hacer a esta tabla, ya sea mediante consultas, actualizaciones o borrados.
Si consultas por ambos criterios deberás de tener dos índices.
Dos índices están duplicados cuando tiene los mismos campos, o uno contiene al otro, pero si se trata de campos diferentes no estás duplicando nada.

Muchas gracias por la respuesta. Aunque sigo sin tener claro cómo abordar el diseño de la tabla salidas. Esta tabla, de manera simplificada tendría los siguientes campos:
-IdSalida (int)

-IdOrigen (int)

-IdDestino (int)
La tabla Entidades sería:
-IdEntidad (int)

-Entidad (varchar)
El problema surge debido a que IdOrigen e IdDestino son los índices que apuntan a IdEntidad. Lo que no entiendo es cómo dos índices de una misma tabla pueden apuntar a un índice de otra.
La verdad es que estoy un poco perdido. Lo puedo hacer así, aunque la integridad referencial se pierda. Y la opción que me queda es hacer tablas auxiliares, aunque complique las consultas sql.
Muchísimas gracias por tu atención.

Me parece que tienes un problema con los conceptos, vamos a ver:
Un índice de una tabla es una estructura de datos que mejora la velocidad de los accesos a los registros de la tabla. O sea que un índice de una tabla POR solo apunta ala tabla POR, y no a otra tabla Y.
Ahora una clave foránea es una restricción que se define en una tabla sobre un campo, que si apunta a, generalmente a la clave primaria de, una segunda tabla. Si yo defino una calve foránea sobre el campo C de la tabla T, que apunte a la PORQUE de la tabla F, al insertar un registro en la tabla T, la base de datos validará que el dato ingresado en el campo C se encuentre en la tabla F.
Y cuando borro un registro de la tabla F, validará que no exista ningún dato en el campo C de la tabla T con el valor a borrar. Por este motivo es recomendable, y no obligatorio, poner índices sobre campos que apuntan a claves foráneas.
En conclusión la clave foránea no es un índice es solamente una restricción, el índice se crea en algunos casos solo para optimizar los procesos.
Entonces si quieres definir controles de integridad en la base de datos mediante claves foráneas (FK) deberás de crear una FK para destino y otra para origen ambas apuntando a la misma tabla. Hasta aquí no creamos ningún índice.
Si tu tabla tendrá un tamaño considerable (digamos más de 10 mil registros), y las entidades pueden ser borradas frecuentemente es conveniente crearle un índice sobre el campo origen y otro sobre el campo destino para que al momento de borrar una entidad lo haga de manera eficiente.
Otra opción es no definir la FK y controlar la integridad de las tablas mediante programas, no es una solución muy académica, pero es más eficiente en términos de performance (claro está corres el riesgo de grabar algo malo).
Los campos que defines en las tablas me parecen correctos. No tienes que crear nada auxiliar.