Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
protogrid:database_design_fundamentals [2018-03-25 22:37] – typos, links und hierarchie dru | protogrid:database_design_fundamentals [2018-03-25 22:39] – dru | ||
---|---|---|---|
Line 3: | Line 3: | ||
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 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 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 | ||
- // | - // | ||
Line 12: | Line 12: | ||
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 // | 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 // | ||
- | === Records = Tuples = Rows = Data Cards === | + | ==== Records = Tuples = Rows = Data Cards ==== |
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 // | 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 // | ||
- | === Attributes = Fields = Columns === | + | ==== Attributes = Fields = Columns |
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 // | 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 // | ||
Line 34: | Line 34: | ||
* etc. | * etc. | ||
- | === Relations === | + | ==== Relations |
Often there are **relations** between entities. | Often there are **relations** between entities. | ||
- | == The 1: | + | === The 1: |
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 // | 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 // | ||
Line 61: | Line 61: | ||
This knowledge is already enough to build many different types of applications. | This knowledge is already enough to build many different types of applications. | ||
- | = How to implement 1: | + | == How to implement 1: |
- 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 | ||
Line 71: | Line 71: | ||
There is one more important variant of relations: | There is one more important variant of relations: | ||
- | == The n: | + | === The n: |
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 102: | Line 102: | ||
- | === 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 |