1)
Well it could be you shouldnt need an arrow at all, however if you need it... it is crucial. If you dont need it is a performance hit that you dont need, outer joins perform a bit less well than inner joins.
Lets try and dream up an example, lets say you have a customer without orders but you want to see all your customers.
Customer ----> Orders
The arrows you only need when you want to see anything always and allow "blank" fields. Usually you have a central table like Customers that you will always want too see... An order without a customer is kind off nonsense.
In your situation, to have a typeoforder without having an actual order is kind off nonsense.
The question then is, is it possible to have an order without knowing what typeoforder it is?
If the answer is Yes then you want tblOrders ----> tblTypeOfOrders
If the answer is No then you want tblOrders ------ tblTypeOfOrders
The arrows even if they "dont seem to do anything" do mean something and have (huge) impact on your database design.
2) for the best performance you ALWAYS want KEY values to be indexed, like your id_status and id_k. It is also quite common to see foreign keys indexed 100%, though this depends a bit on you database design.
If for example you want to search quite often on your status (inside your tblStatus) and find the tblZlecenia (orders?) that go with that status then you definately want that FK to be indexed.
If your FK is simply a reference field that will never be searched then you can concider skipping the Index.
Simularly any field (of a significant size table, lets say 10.000 records or more) that will be searched a lot will want/need an index.
If you stick to those kind of rules, you should be good enough index and performance wize.
Without knowing very much the details of your database and requirements, I cant tell you which columns to index and which not to index....