Attribute and its Types
--
● Attribute: Attribute describes the property of the entity of which they are associated.
Or Characteristics
▪ of an entity is called attribute.
● Attribute are as follows.
1- Simple or atomic attribute
2- Composite attribute
3- Single-valued attribute
4- Multi-valued attribute
5- Derive attribute
1. SIMPLE OR ATOMIC ATTRIBUTE
▪ An attribute that cannot be divided into smaller independent attribute is known as Simple or atomic attribute.
▪ For example, assume Student is an entity and its attributes are Name, Age, Address and Phone no. Here the age (attribute) of student (entity) cannot further divide. In this example age is atomic attribute.
2. COMPOSITE ATTRIBUTE
An attribute that can be divided into smaller independent attribute is known as composite attribute.
▪ For example, assume Student is an entity and its attributes are Name, Age, Address and Phone no. Here the address (attribute) of student (entity) can be further divide into House no, city and so on. In this example address is atomic attribute.
3. SINGLE VALUED ATTRIBUTE
▪ An attribute that has only single value for an entity is known as single valued attribute.
▪ For example, assume Student is an entity and its attributes are Name, Age, Address and Phone no. Here the age (attribute) of student (entity) can have only one value. Here, age is single valued attribute.
4. MULTI VALUED ATTRIBUTE
▪ An attribute that can have multiple values for an entity is known as multi valued attribute.
▪ For example, assume Student is an entity and its attributes are Name, Age, Address and Phone no. Here the Phone no (attribute) of student (entity) can have multiple value because a student may have many phone numbers. Here, Phone no is multi valued attribute.
5. DERIVED ATTRIBUTE
▪ An attribute that can be derived from another attribute is known as derived attribute.
▪ For example, an age could be calculated once a student’s birthdate is entered.
◆ Degree of Abstraction
● Data Abstraction
▪ Data Abstraction refers to the process of hiding irrelevant details from the user. So, what is the meaning of irrelevant details? Let’s understand this with one example. Example: If we want to access any mail from our Gmail then we don’t know where that data is physically stored i.e. is the data present in India or USA or what data model has been used to store that data? We are not concerned about these things. We are only concerned with our email. So, information like these i.e. location of data and data models are irrelevant to us and in data abstraction, we do this only. Apart from the location of data and data models, there are other factors that we don’t care of. We hide the unnecessary data from the user and this process of hiding unwanted data is called Data Abstraction.
▪ There are mainly three levels of data abstraction and we divide it into three levels in order to achieve Data Independence. Data Independence means users and data should not directly interact with each other. The user should be at a different level and the data should be present at some other level. By doing so, Data Independence can be achieved. So, let’s see in details what these three levels of data abstraction are:
1. View Level
2. Conceptual Level
3. Physical Level
● View Level or External Schema
▪ This level tells the application about how the data should be shown to the user. Example: If we have a login-id and password in a university system, then as a student, we can view our marks, attendance, fee structure, etc. But the faculty of the university will have a different view. He will have options like salary, edit marks of a student, enter attendance of the students, etc. So, both the student and the faculty have a different view. By doing so, the security of the system also increases. In this example, the student can’t edit his marks but the faculty who is authorized to edit the marks can edit the student’s marks. Similarly, the dean of the college or university will have some more authorization and accordingly, he will have his view. So, different users will have a different view according to the authorization they have.
● Conceptual Level or Logical Level
▪ This level tells how the data is actually stored and structured. We have different data models by which we can store the data. Example: Let us take an example where we use the relational model for storing the data. We have to store the data of a student, the columns in the student table will be student_name, age, mail_id, roll_no etc. We have to define all these at this level while we are creating the database. Though the data is stored in the database but the structure of the tables like the student table, teacher table, books table, etc are defined here in the conceptual level or logical level. Also, how the tables are related to each other are defined here. Overall, we can say that we are creating a blueprint of the data at the conceptual level.
● Physical Level or Internal Schema
▪ As the name suggests, the Physical level tells us that where the data is actually stored i.e. it tells the actual location of the data t hat is being stored by the user. The Database Administrators (DBA) decides that which data should be kept at which particular disk drive, how the data has to be fragmented, where it has to be stored etc. They decide if the data has to be centralized or distributed. Though we see the data in the form of tables at view level the data here is actually stored in the form of files only. It totally depends on the DBA, how he/she manages the database at the physical level.
◆ Degree of Relationship and its Types
● A relationship degree indicates the number of entities or participants associated with a relationship.
● There are three types of degree of Relationship.
1. Unary Relationship
2. Binary relationship
3. Ternary Relationship
▪ A unary relationship exists when an association is maintained within a single entity. A binary relationship exists when two entities are associated. A ternary relationship exists when three entities are associated. Although higher degrees exist, they are rare and are not specifically named. (For example, an association of four entities is described simply as a four-degree relationship.)
1. Unary Relationships
● A unary relationship exists when an association is maintained within a single entity.
▪ In the case of the unary relationship shown in the following Figure an employee within the EMPLOYEE entity is the manager for one or more employees within that entity. In this case, the existence of the “manages” relationship means that EMPLOYEE requires another EMPLOYEE to be the manager — that is, EMPLOYEE has a relationship with itself. Such a relationship is known as a recursive relationship.
2. Binary Relationships :
▪ A binary relationship exists when two entities are associated in a relationship. Binary relationships are most common. In fact, to simplify the conceptual design, whenever possible, most higher-order (ternary and higher) relationships are decomposed into appropriate equivalent binary relationships. For example the relationship “a PROFESSOR teaches one or more CLASSes” represents a binary relationship.
3. Ternary and Higher-Degree Relationships
▪ Although most relationships are binary, the use of ternary and higher-order relationships does allow the designer some latitude regarding the semantics of a problem. A ternary relationship implies an association among three different entities. For example, note the relationships (and their consequences) in the following Figure which is represented by the following business rules:
▪ A DOCTOR writes one or more PRESCRIPTIONs.
▪ A PATIENT may receive one or more PRESCRIPTIONs.
▪ A DRUG may appear in one or more PRESCRIPTIONs.
▪ (To simplify this example, assume that the business rule states that each prescription contains only one drug. In short, if a doctor prescribes more than one drug, a separate prescription must be written for each drug.)
◆ Relationship Strength
▪ Relationship strength is based on how the primary key of a related entity is defined.
There are two types of Relationship Strength
1. Strong Relationship (identifying)
2. Weak Relationships (non-identifying relationship)
● Strong Relationship (identifying)
▪ Exists when the PK of the related entity contains the PK component of the parent entity.
▪ Strong entity is not dependent of any other entity in schema. Strong entity always has primary key. Strong entity is represented by single rectangle. Two strong entity’s relationship is represented by single diamond. Various strong entities together makes the strong entity set.
● Weak Relationships (non-identifying relationship)
▪ Exists if the PK of the related entity does not contain a PK component of the parent entity.
▪ Weak entity is depend on strong entity to ensure the existence of weak entity. Like strong entity weak entity does not have any primary key, it has partial discriminator key. Weak entity is represented by double rectangle. The relation between one strong and one weak entity is represented by double diamond.
