To quote Joe Celko (not only can you find this reference all over the web and in his Wikipedia entry, but you will even see it on T-shirts at some conferences):
Rows are not records.
A lot of people point him out as a pedantic jerk who just likes to humble and verbally abuse newbies, and I will admit that is how he comes across. But I have also met him in person - even shared a meal with him - and I can't tell you how different his real-life persona is from his online front. I even once caught him calling rows records, and he was very embarrassed (full backstory here).
In any case, say what you will about the guy's online character, but he wrote the standard, and the fact that such an authority dictates that there is a distinction should tell you something. And as much as he cringes when someone calls a row a record, so do many of my colleagues - who are also experts in the SQL Server world. And those of us in that camp believe he is right.
For example, Itzik Ben-Gan, an obvious SQL Server guru. Here is a quote from the very first lesson in his Training Kit (Exam 70-461): Querying Microsoft SQL Server 2012:
As an example of incorrect terms in T-SQL, people often use the terms “field” and “record” to refer to what T-SQL calls “column” and “row,” respectively. Fields and records are physical. Fields are what you have in user interfaces in client applications, and records are what you have in files and cursors. Tables are logical, and they have logical rows and columns.
And, knowing Itzik, if you send him an e-mail or corner him at a conference he will happily tell you the same. If you call a row a record, in his opinion, you're not using the terminology correctly.
Now, being an industry full of folks of all kinds, you are likely to find material (such as the tech target articles posted in another answer) that seem to make very subtle distinctions between the two, and you will find many people in the industry consider them the same (I know several folks at Microsoft, and other folks like Brent Ozar, who will just always call it a record). That doesn't make them right, that's just their way of looking at it - they view logical and physical as the same (at least in this context) and many of them probably think the rest of us are just anal retentives spending too much time on semantics.
Since no vendor gets to say "thou shalt call them {records|rows}", we will forever be dealing with this argument, because there will always be someone who doesn't get the logical vs. physical, or was taught differently, or came from Access or programming backgrounds, etc. Just like some people say tomay-to and other people say tomah-to, there will always be a variety of people who range from "they're the same" to "they're completely different" - and many shades in between. Again, that doesn't make any of them right, because nobody can be the ultimate authority on this. But in the SQL Server space, there is definitely a majority.
That said, IMHO, when you are talking about data that is in a table, you call it a row. When you are performing an insert, you are inserting a row into a table. When you run an update, you are updating a row that is in a table. And when you perform a SELECT, you are retrieving rows from a table.
Feel free to call it a record once your application has a hold of it. But don't get angry if you say, "I inserted a record," and someone corrects you.
There are basically just two things here:
Your data model, which is the structure of your entities, attributes and relationships.
The graphical representation of your data model.
Your data model may be high level (entities/relationships only) or lower level (add in attributes with details of data types) and it may be logical or physical. It all depends on what stage of your design process you're at. The point of a data model is to record your database design, which is just an expression of your business requirements for persisting data.
Crows foot and ERD etc. are just graphical conventions for showing your data model pictorially. The great thing about standards is that there's so many to choose from, and this is also true of graphical conventions. Read this wiki article for a sampling.
Which conventions you choose may depend on what you need to communicate about your model, or it might just depend on what conventions make sense to you.
Don't get too wound up about all the different terminology. It's all just your database design and how you choose to record and communicate it.
Best Answer
Well, the data dump is the data itself, i.e. the questions, answers, comments, user information etc. of the Stack Exchange sites. Note that on Stack Exchange, 'data dump' usually refers to something else than SEDE: a quarterly dump of the data published in XML format. It contains more or less the same information as SEDE (which is the reason the schema Q&A is shared between them), but in a different format, and it isn't updated as often as SEDE is (SEDE is updated once a week, on Sunday morning).
There is no formal data dictionary for the entirety of SEDE; most of the schema documentation can only be found in the Database schema documentation for the public data dump and SEDE and isn't available as a database/repository/API itself. The schema is rather small and schemas of this size don't benefit as much from a data dictionary as large-scale applications like ERP software does.