• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 71
  • Last Modified:

correct terminology for core record stored in a database/app

Is there any specific terminology you use when it comes to applications/databases in relation to the core record the system stores. We need to do a set of data quality testing against any of our databases/applications which collect personal information (e.g. name, date of birth, nationality, address, contact details, e.g. email, phone etc).

We are trying to explain to our DBA's that we do not require an extract of every table in the database as in 99% of the cases these do not store the 'core record' relating to the individual. I am trying to identify if in data analysts/database admins worlds whether there would be any sort of useful terminology we can use to describe the 'core record' the system stores, as most applications have a purpose, e.g. payroll/HR stores data about employees, so the core record is the employee record, whereas a customer database core record would be the customer, purchasing core records would be the supplier or customer, but its trying to word what I keep using as the 'core record' in a way others may understand. Whereas I appreciate the system will associate other information against these core records, its the core records we need to analyse. A hospital database core record would be the 'patient' etc. The phrase 'core record' doesn't seem to be the correct terminology based on the confused response I am getting, but I am after some other possible terminology which may be and may make a little more sense for our requests.
6 Solutions
Vitor MontalvãoMSSQL Senior EngineerCommented:
Perhaps "Main table"?
Shaun VermaakTechnical Specialist/DeveloperCommented:
Denormalized record?
ValentinoVBI ConsultantCommented:
Maybe "Master Data"? Or "core master data"?

The term Master Data is broader (i.e. company-wide, not just one DB) but it does define the business-important data.

Ref. Master Data (Wikipedia)
Improve Your Query Performance Tuning

In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!

yes, the relation between a table and its dependent tables is called "master - detail" or sometimes "parent - child". it normally means that the detail table has a primary key which consists out-of the primary key of the master table + an individual detail id (often a unique consecutive number related to the master id).

master-detail relations are different to common foreign key relations, because a detail record only can have one master record, i. e. it is a 1:n relation while foreign key relations may be multiple or nullable or may not be a hierarchical relation.

Jim HornMicrosoft SQL Server Developer, Architect, and AuthorCommented:
>We are trying to explain to our DBA's that we do not require an extract of every table in the database as in 99% of the cases these do not store the 'core record' relating to the individual.

DBA's are typically involved in backup/restore, availability, and in some cases performance tuning.  They are not typically involved in logic that dictates which rows should be extracted and which do not, as that is a development task.

90% of the DBA's I've known if given this task would reply with a :: blank stare :: and something like 'Sounds like something you need to figure out.  Let me know when you have an actionable task for me.'

So I suggest that you, or a supporting development team if you are not a SQL Server developer, figure out this logic on your own so that it can be executed to meet your needs.
Geert GOracle dbaCommented:
there is no such thing as a core record.
it's just records in tables.

a database is there for holding information and retrieving it
a database can hold multiple schemas, like HR, SALES, etc ...

an ERP system can have the complete company in 1 database
that's customers, vendors, employees ... you name it

you'll need to indentify the functional equivalent
your example already does that ... an employee is described via a record in the employees table
for functional requests, you shouldn't be going to a dba

a dba usually has no clue what functionalities the databases support
a dba doesn't require that knowledge.
in 95% of the cases a dba has access to all the tables, but that doesn't mean you have to go to the dba for info

a bankdirector usually  has access to the vault ... doesn't mean he knows what's in the vault
Mark GeerlingsDatabase AdministratorCommented:
I'm not aware of any standard terms to describe what you describe as "core records".  That may be partly because many business systems are not as simple as just storing one type of "core record" like the examples you gave:
1. employee records in an HR system
2. supplier/vendor records in a purchasing system
3. customer records in a sales tracking system

It is also not clear from your question if you are most interested in the core records in the system (like: item master records in an inventory system, or bill-of-material records in an engineering system, for example) or if you are mainly interested if person-related records regardless of the type of system.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now