I assume that you don’t have the help files or documentation for Access. There is a sample database called Northwind that comes with it. It is set up to show common applications and provide examples of how to apply them.
Search the Access directory for Northwind and if it’s there, google for examples of how it can be used.
See, this is why i suggested Scribe or some other frontend that you simply plug your information into, and that keeps the database hidden in the backend.
If you can’t see the difference between Access and Excel, it suggests that you don’t yet understand the key benefits of a relational database management system. There’s nothing wrong with that; everyone has to start somewhere. But it’s a bit of a learning curve, and if you don’t even know about the principle of joining tables using things like foreign keys, you’re probably going to spend a long time working out what you want to do.
The benefits of a proper relational database are precisely that you have different tables for different data, and that you link these tables in ways that ensure that data is not repeated unnecessarily, and that the data is broken down into the smallest constituent elements possible. This takes best advantage of the power of the database, and allows for much more specific and granular searches than a flat file like Excel.
For example, you say in your OP that, for each latin word in your collection, you want to “create a record … with a number of fields for sources, keywords, notes, etc.” In Excel or some other flat file system, this inevitably leaves you with records of varying length, and become unwieldy and hard to search in meaningful ways, and also duplicates information in unnecessary ways. The database overcomes those problems, but only if it’s set up right. The longest process in most database construction is the design part, where you decide exactly what data you want to incorporate, and how it will be organized.
For example, if you’re allocating keyword to each entry, there’s a good possibility that not all entries will have the same number of keywords, right? Entry 1 might be associated with 2 keywords, while Entry 2 might have 4 or 5 keywords.
To represent this in a single table, you either have to:
a) place all keywords in a single cell, separated by something like a comma or a semi-colon, like this:
Entry 1 Keyword 1,
Keyword 2
Entry 2 Keyword 1,
Keyword 2,
Keyword 3,
Keyword 4,
Keyword 5
or
b) put each in a separate cell, meaning that each entry in your table has an unequal number of columns, like this:
Entry 1 Keyword 1 Keyword 2
Entry 2 Keyword 1 Keyword 2 Keyword 3 Keyword 4 Keyword 5
While this can sometimes work for small tables, as your collection grows, it becomes ugly and, more importantly, unwieldy. It becomes difficult to search, and almost impossible to collect and group entries by certain keywords. How, for example, to you run a search that finds all entries with Keyword 2 and Keyword 4, but not Keyword 5, and then groups them in order of date?
The great advantage of a proper database is that you store your keywords (or other repeated data) in a completely different table, and then reference them from the table that contains your main entries. This keeps the different types of data separate, eliminates unnecessary duplication, and makes for much more powerful searching.
For an introductory look at the steps required to organize your data in a database, i recommend having a look at the issue of database normalization. While it sounds technical, and might seem at first to be difficult, the principles are actually quite sensible and straightforward. Here’s one introductory tutorial on normalization, and there are dozens of other out there.