Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
protogrid:database_design_fundamentals [2017-11-16 04:53] – mmuprotogrid:database_design_fundamentals [2018-03-26 07:49] (current) – [Database Design Fundamentals] 77.58.53.50
Line 1: Line 1:
 ====== Database Design Fundamentals ====== ====== Database Design Fundamentals ======
  
-Database design is an important task for each software developer. It is in most software development projects crucial to understand the real world problem thoroughly and be able to design the most simple database design possible. The key to success is as well a good understanding of the problem given as a the ability to simplify the real world to a good model. The most talented designers master the art of designing a data model that is universal and versatile and continues to work unchanged when there will be added entities and attributes in the future.+Database design is an important task for each software developer. It is in most software development projects crucial to understand the real world problem thoroughly and to be able to design the most simple database design possible. The key to success is as well a good understanding of the problem given as the ability to simplify the real world to a good model. The most talented designers master the art of designing a data model that is universal and versatile and continues to work unchanged when there will be added entities and attributes in the future.
  
-=== Entities ===+==== Entities ====
 The real world is full of objects. If you look around you and think a bit you will find The real world is full of objects. If you look around you and think a bit you will find
   - //physical// and tangible objects like houses, dogs, cars etc.   - //physical// and tangible objects like houses, dogs, cars etc.
Line 10: Line 10:
 We call each class of objects of the same type //entity// (from latin ens //being//). We call each class of objects of the same type //entity// (from latin ens //being//).
  
-An entity is usually represented in software by a form. In table-oriented databases, an entity can also very easily be understood and represented as a table (consisting of rows and columns). In Protogrid, each entity is defined as a //Proto//, a special Design Card that is used to define the attributes, appearance and behaviour of Data Cards.+An entity is usually represented in software by a form. In table-oriented databases, an entity can also very easily be understood and represented as a table (consisting of rows and columns). In Protogrid, each entity is defined as a //[[Proto]]//, a special Design Card that is used to define the attributes, appearance and behaviour of Data Cards.
  
-== Records = Tuples = Rows = Data Cards == +==== Records = Tuples = Rows = Data Cards ==== 
-Entity records have different names in different names in literature. In table-oriented databases it is represented as a table row. More generally it is called a tuple, i.e. a set of attributes defined in an entity. In Protogrid, records are represented as //Data Cards//. An entity usually has many records. Each record has a unique key that allows to identify the record. In Protogrid, that key is called a //Card Key//.+Entity records have different names in literature. In table-oriented databases it is represented as a table row. More generally it is called a tuple, i.e. a set of attributes defined in an entity. In Protogrid, records are represented as //[[protogrid:card|Data Cards]]//. An entity usually has many records. Each record has a unique key that allows to identify the record. In Protogrid, that key is called a //Card Key//.
  
-== Attributes = Fields = Columns == +==== Attributes = Fields = Columns ==== 
-An entity has attributes. Each attribute describes a part of the entity. In table-oriented databases, an an attribute is represented as a table column. In Protogrid, attributes are represented as //fields// on a Data Card, and are defined using //Field Definitions// on the Proto. +An entity has attributes. Each attribute describes a part of the entity. In table-oriented databases, an attribute is represented as a table column. In Protogrid, attributes are represented as //[[protogrid:field|fields]]// on a Data Card, and are defined using //Field Definitions// on the Proto. Field Definitions are another type of Design Card, responsible to define the behaviour and appearance of fields.
  
 As an example, a house might have the following attributes: As an example, a house might have the following attributes:
Line 34: Line 34:
   * etc.   * etc.
  
-=== Relations === +==== Relations ==== 
-There are **relations** between entities: +Often there are **relations** between entities. 
-  * mother-child-relations: there might be many, one or no child, we call this a 1-to-many-relation and write 1:n, with //n// representing the variable number of children. //1// and //n// are often called the //cardinality// of an entity in a relationship. In database design, the variable //n// is usually repeated for each of the relations, even though it represents a different number in each.+ 
 +=== The 1:n-relation (Mother-Child Relations) === 
 +For one mother there might be many, one or no child. We call this a 1-to-many-relation and write 1:n, with //n// representing the variable number of children. //1// and //n// are often called the //cardinality// of an entity in a relationship. In database design, the variable //n// is usually repeated for each of the relations, even though each represents the cardinality of a different entity.
  
 Many times we see mother-child-relations: Many times we see mother-child-relations:
Line 52: Line 54:
  
 How do we represent these relations in a software's user interface? How do we represent these relations in a software's user interface?
-  * the mother entity is form with fields+  * the mother entity is a form with fields
   * the child entity is also a form with fields   * the child entity is also a form with fields
-  * on the mother form we have a view showing all children+  * on the mother form we have an embedded view showing all children
   * on the child form we have a field that shows us the name of the mother and a button or link to go to the mother form   * on the child form we have a field that shows us the name of the mother and a button or link to go to the mother form
  
-With this knowledge we can build many different types of applications.+This knowledge is already enough to build many different types of applications.
  
 == How to implement 1:n-relations in Protogrid == == How to implement 1:n-relations in Protogrid ==
-  - create the Proto for the child entity+  - create the [[Proto]] for the child entity
   - create the Proto for the mother entity   - create the Proto for the mother entity
-  - add a TableView to the mother Proto which relates to the child Proto +  - add a [[TableView]] to the mother Proto which relates to the child Proto 
-  - add a relation field to the child Proto which relates to the mother Proto +  - add a relation [[field]] to the child Proto which relates to the mother Proto 
-That's all folks! It is very simple in Protogrid. This is where Protogrid truly shows its Rapid Application Development capabilities.+ 
 +That's all folks! It really is that simple in Protogrid. This is where Protogrid truly shows its Rapid Application Development capabilities.
  
-There is one more important variant: +There is one more important variant of relations:
  
-== The n:m-relation ==+=== The n:m-relation ===
  
 Sometimes a child has not only one related entity (like a mother - there is only one for each child on this planet) but many. The closest example to think of are siblings. Sometimes a child has not only one related entity (like a mother - there is only one for each child on this planet) but many. The closest example to think of are siblings.
Line 76: Line 79:
   - a person might be member of several organizations and an organization has usually several members   - a person might be member of several organizations and an organization has usually several members
  
-Any n:m-relation might be split into two 1:n-relations+For the sake of simplicity any n:m-relation might be split into two 1:n-relations
  
 Examples: Examples:
Line 89: Line 92:
  
 == How to create an n:m-relation in Protogrid == == How to create an n:m-relation in Protogrid ==
-  - create the first proto (e.g. the organization) +  - create the first [[Proto]] (e.g. the organization) 
-  - create the second proto (e.g. the person) +  - create the second Proto (e.g. the person) 
-  - create the relation proto with only two fields of type relation, pointing to the first and the second proto, respectively. +  - create the relation Proto with only two fields of type relation, pointing to the first and the second Proto, respectively. 
-  - go to the first proto and add a tableview with the relation proto +  - go to the first Proto and add a [[TableView]] with the relation Proto 
-  - go to the second proto and add a tableview with the relation proto+  - go to the second Proto and add a TableView with the relation Proto
  
-Now you can see in the first proto in a tableview all relations to the other proto. +In Cards of the first Proto you now can see all relations to the other Proto. 
-And you can see in the second proto in a tableview all relations to the first proto, which is exactly what we need in most cases.+And in Cards of the second Proto you can see all relations to the first Proto, which is exactly what we need in these cases.
  
  
-=== Summary === +==== Summary ==== 
-  * Entity ~ form ∼ table - Proto +  * Entity ~ form ∼ table ~ Proto 
-  * Record ~ row in a table - Data Card +  * Record ~ row in a table ~ Data Card 
-  * Attribute ~ column in a table - field+  * Attribute ~ column in a table ~ field

Trace:

Print/export