There are a variety of factors that would cause IT organizations to be cautious about creating databases and giving business users the level of access to those systems that you are, presumably, asking for when you talk about wanting to "play with" the data.
First off, since you're in a company that does trading, that implies that there are dozens of laws and agencies that regulate the company. In order to comply with those laws, your organization undoubtedly has put together dozens if not hundreds of policy documents that undoubtedly include policy statements that say things like only members of the DBA team have superuser privileges to modify data in databases, only changes that go through the official software development lifecycle are promoted to production, a separation of duties ensures that people that administer the database are different from people that code against the database which are different from people that input and maintain the data. The first step of the many, many audits that such an organization goes through is to check to see whether the policies in those documents matches the actual practice. Finding "rogue" databases that exist outside of these policies is a huge red flag in such an audit. Even if your database didn't actually create any real risk, it would create an audit finding because it violated the agreed-upon policies. Theoretically, the IT organization could work with their regulators to amend the dozens of policies to allow this sort of thing in special cases, but that would likely be a tremendous amount of work.
It is unlikely, though, that regulators would view the sort of risk analysis that you're talking about as the sort of thing that might get a pass from the burden of regulation. The process of building risk models and analyzing risk in a trading business is about as core a concern of regulators as you're going to find. Regulators are going to want someone to be able to explain exactly what sort of analysis is being done, what data sources are being used, how that data is being manipulated, etc. They're going to want to know who has access to that data, how it is backed up, etc.
Second, systems like the one you describe have a tendency to grow over time and often get dumped on IT organizations once they become unwieldy or when the original owners move on. A system that you set up today just for yourself to play with can quickly become a system that your department depends on and then a system that is integrated with all sorts of reporting and workflow processes as time goes on. At some point, though, you'll move on to another company or the system will get slower or someone will realize that some critical bit of the business depends on a system that is running with no backups on some guy's machine and then IT will get the call to own the system. Those projects are generally train wrecks. These systems aren't generally designed well (risk analysts generally come up with better software designs than software developers come up with risk models but both pursuits benefit from expert attention up front), they're not properly documented, etc. They also tend to rely on tons of manual processes that scale acceptably when one business user owns the process and understands in detail what the system is doing and why but that scales incredibly poorly when IT folks are trying to simultaneously manage many different systems that they don't understand in deep detail. IT organizations generally do everything they can to prevent these systems from sprouting in the first place because they turn into such hassles in the end.
Third, if the system that you're building is necessary for you to do your job, then it's likely that it needs the attention of IT. It probably needs to be backed up, for example. It probably needs to be added to various proactive and reactive monitoring scripts/ systems that the DBAs monitor in order to ensure that sufficient disk space is available, that the workload of your system isn't crushing other systems, etc. It probably needs to be part of the disaster recovery plan (if only to note that it's a low priority system to restore). It needs to get added to the set of systems that the DBAs patch when security updates come out or when the enterprise upgrades to new versions of the database. It needs to get added to the support contract so that it doesn't raise issues when the company gets audited by the vendor. These things are generally much harder when IT doesn't own the system. But if IT owns the system, it needs to behave like all the other IT systems-- it needs to be developed by developers, used by users, administered by administrators, it needs to have different environments (dev, test, staging, prod) to support the standard development models, etc.
In most IT organizations, if you need this sort of setup, you would need a project to create it (which would include things like assigning development resources, a project manager, etc.) That project obviously needs to be prioritized, implemented, etc.
If you really want "free reign" to do whatever you want without any of the controls that are put on developers, it's possible that you, your manager, and IT could get together and come up with a reasonable compromise. Perhaps you could be given slightly elevated privileges in some database/ schema somewhere along with restrictions in the types of things you're allowed to do (i.e. nothing from what you're doing can feed any other system, nothing can be used in a production process, etc.) It's not uncommon for analysts to have a "playground" where they can create tables to support ad hoc reporting, for example, with the understanding that anything that needs to become part of a production report needs to get built following the full development lifecycle process.
Best Answer
This appears to be a fairly standard multi-site case. Model the data as if there is only one location. This will get the basic model down correctly. Then add a location column to the tables where location is important. Options you may want to use are:
I would remove AUTOSHOP entirely, you should attributes that are appropriate for LOCATION. Depending on how you are modelling PRODUCT, it may be fine. The AUTOSHOP stock PRODUCT relationship, likely should be an INVENTORY table. SALES (Invoices) usually have line items which may be either SERVICES or PRODUCT. I find it is better to model in the general and specialize as needed. The EER model is intended to make specialization simpler.
From a business perspective, I see three related subsystems: Sales, Inventory, and Purchasing. These three systems will all share Product, and Location data. In a single site system Location would not be required, or at least would not need to relate to the other tables.