Entities, Attributes, Domains, and Data Relationships

I have not posted in a while.  Today I'm going to discuss entities, attributes, domains, and data relationship in a very simple form. 

This discussion will focus on deliberating the facts that database designers need to make things happen in the real world.  See there are those who have to deliver real systems in order to meet real customer’s business needs and there are those who will simply stick to end-user process.  They don’t have a need to concern themselves with the little important aspects of database design and the behind the scene details that make up a database, for this reason alone it would be difficult to explain what a database is all about.

A database is composed of entities and attributes, and it includes relationships among the different entities.  These relationships may and may not be necessary therefore they could be mandatory or not.   This is depends upon the data to be managed and processed.   According to Kemp (2008) the definition of an object class, the attributes belonging to the class and the details describing the valid values or domain for each attribute are defined within a data dictionary that accompanies the database design schema.   This is also dependent upon the clients understanding of their company and the data they need to work with. 

It is very important that the clients understand all aspect of their own business either internally or externally is good idea to have an understanding of a business and the ways different things happen within the business.  CEO’s, DBA’s,  and  employees who are not aware of their own business processes will certainly have a difficult time excelling, managing, and performing particular roles.

The facts are simple, in order to understand how to work with entities and attributes and its set of relationships one must be looking at some basic information:  As a DBA or consultant we must deliver the content to in a way that is understood. According to Naiburg & Maksimchuk (2001) whether you work within the company or as an outside consultant, when you look at the company you can begin to understand the major mission of the business and how things operate.

 We must understand how client’s either internally or externally perceive and view the business.  What do these clients believe about the company and what they need to do in order to have a successful data management system?  These clients must also understand what is wrong and how they can fix it, and last how these clients will perform their activities in relation to data management.

We must intelligently communicate with our clients while at the same time delivering on hand brief training process of what data is, the requirements, and how to gather data in order to have a successful data management process.  The terminology of entities, attributes, domains, and data relationships can be easily explained to a non-technical individual but one must understand and find ways how to clearly deliver this frustrating technical content without creating frustrations.  The way to explain these subject is to take the clients by the hand and allow them to think about attributes of a subject they have affinity for and or care about, and the relationships among it and how they will visualize and support their understanding and thinking of it.  The facts are simple and the analysis is how ascertained the data will fit into the user's business processes.

For the sake of simplicity the point is the completeness of the data and this is what we must be able to explain to our clients.  Gathering data and information work best when it is correct, complete, and validated.  This is corroborated by Adelman, Moss, and Abai when they say that the; Data validity rules govern the quality of data values, also known as data domains.  According to these authors we need to consider six data validity rules:  completeness, correctness, accuracy, precision, uniqueness, and its consistency.

Reference

Karen K. Kemp., K. K. (2008).  Encyclopedia of geographic information science.  Edition   illustrated.  SAGE

Naiburg, E. j. & Maksimchuk, R. A. (2001).  UML for Database Design.  Addison-Wesley Professional

Sid Adelman, S., Moss, L. T., and Abai M. (2005). Data Strategy, Addison-Wesley Professional