Where conceptual data modeling is used primarily for the envisioning requirements for your database, a logical data model is used to explore the entity types and their relationships to other entities. A physical data model is what we use to truly design traditional projects. The internal database schema design is helpful for an application developer to better understand the functionality of data oriented objects of a project and therefore important for this developer to know how best to program a business application that must interact with a complex business database.
Where conceptual data modeling is used primarily for the envisioning requirements for your database, a logical data model is used to explore the entity types and their relationships to other entities. A physical data model is what we use to truly design traditional projects. The internal database schema design is helpful for an application developer to better understand the functionality of data oriented objects of a project and therefore important for this developer to know how best to program a business application that must interact with a complex business database.
Suppose you want to extract specific data from a collection of data entities from an order entry system and have it organized in one logical platform such as tables or columns. For example, customers place orders on a specific data and time, customers live at addresses that you will ship to and the billing address may be different for the shipping address. The relationships between these entities are “Placed by”, “Billed to”, “Shipped to” & “Lives at”. The entities themselves are the customer names, products ordered and address within the customer class. In the database ER design , there are about five factors to follow through in database modeling.
1. The relevant entities: Entities are simply the individual data objects within the database that has importance or a value. An entity type could represent a collection of people, places, things and events.
2. Relevant Attributes of Entities: Say the entity is an employee. Some of the attributes of that employee is that they have a “FIRST_NAME” and a “LAST_NAME”. Some other attributes are his log-in information into a timesheet reporting system. Getting the level of detail right can have a significant impact on your database development efforts. Entity naming conventions should be established and followed to avoid any confusion as you add data fields over the course of time.
3. Relationship between Entities: As you are about to identify the needed entities, you will be able to draw out a similarity or a common concept among each element. This is called the relationship or better yet, a linking idea that determines the similarity of two or more entities from each other. Example, employee A and employee B work on the same shift, which is a dayshift. The “Dayshift” is the apparent relationship.
4. Data Tables: Tables store data as collections of entities. Entities are similar to rows. An entity has a primary key and a set of properties.
5. Keys Representing Relationship: Assigning a Key is probably the most crucial step a programmer would take. The process entails the creation of would-be queries that represents relationships as it would be the only way that users will be able to access data from the database.
2. Relevant Attributes of Entities: Say the entity is an employee. Some of the attributes of that employee is that they have a “FIRST_NAME” and a “LAST_NAME”. Some other attributes are his log-in information into a timesheet reporting system. Getting the level of detail right can have a significant impact on your database development efforts. Entity naming conventions should be established and followed to avoid any confusion as you add data fields over the course of time.
3. Relationship between Entities: As you are about to identify the needed entities, you will be able to draw out a similarity or a common concept among each element. This is called the relationship or better yet, a linking idea that determines the similarity of two or more entities from each other. Example, employee A and employee B work on the same shift, which is a dayshift. The “Dayshift” is the apparent relationship.
4. Data Tables: Tables store data as collections of entities. Entities are similar to rows. An entity has a primary key and a set of properties.
5. Keys Representing Relationship: Assigning a Key is probably the most crucial step a programmer would take. The process entails the creation of would-be queries that represents relationships as it would be the only way that users will be able to access data from the database.
These five elements are just an overview of the basics associated with a more complex process. ER diagrams for entity relationship models is the most commonly used principles for database modeling.
There are actually many diagramming tools on the market. Some of these db design tools are more robust than others. Most programmers have a preference to their database ER design software of choice. This preference of design software for a database often varies greatly between database designers.
No comments:
Post a Comment