Please note: this project is inactive since early 2006

2.2 Concepts

In this section we give a general idea on the Models and their elements. The details for the different parameters will be reviewed in detail in the next section.

E.-R. Modelling defines:

they map one-to-one with classes. An Entity holds all informations needed to make the instances persistent, including: Attributes, Relationships, and other informations (such as the name of the DB's table in which instances' values are ultimately stored)

they can be of two kinds. Some map the attributes/fields of your classes to their column's name in their Entity's table, others have no existence at all at the object-level: they are artifacts, such as ''primary keys'' or ''foreign keys'', needed to design a relational database schema.

relationships are, rougly speaking, half of an association. Relationships are defined in Entities. A Relationship is uni-directional, from the entity that holds it (the ''source entity'') to the ''destination entity''. A Relationship may have an inverse relationship. A relationship also holds its cardinality, and is said to belong to one of these two categories: to-one and to-many relationships. Let's illustrate this with a little example.

Say you have two entities, Book and Writer (this refers to the model definied in section 2.1.1); these two entities are in relation to each other: the Book defines a relationship named toAuthor, pointing to Writer, and Writer has in turn a relationship toBooks pointing to Book. Each of these relationships is the inverse of the other. The former, toAuthor, designates e.g. exactly 1 author, while the second one designates 0 or n books, with n being a positive integer.

In this case 1 is said to be both the lower and the upper bounds of the toAuthor relationship's multiplicity, while for toBooks 0 is the lower bound and * (meaning: any positive number of books) is the upper bound. The former is said to be a to-one relationship (1 is the upper bound), the latter, a to-many relationship (the multiplicity's upper-bound is -strictly- greater than 1).

Joins have no meaning at the object-level; you will not explicitly see or even define Joins in PyModels, or in the ZModelization tool interface -they are defined along with the relationship's definition. Joins are, again, artifacts defining how a relationship is made persistent into a database; more explicitly, a join has a source attribute and a destination attribute, both of which have no meaning at all at the object-level (they are not class' fields). Typically, a to-one relationship has Joins joining foreign keys to primary keys, while to-many relationships have joins whose source attributes are primary keys and destination attributes are foreign keys (see ''Designing relationships'', below, for details)

Additionally, we define Models and Model Sets.

A model groups entities together. It holds specific informations about the underlying database itself, such as the connection dictionary, and it gathers Entities which are to be made persistent within the same database.

Model Sets are, as the name suggest it, sets of models. The Framework itself only deals with one ModelSet, accessible by calling defaultModelSet() on module Modeling.ModelSet.

Comments are welcome: Sebastien Bigaret / Modeling Home Page
Hosted Logo