Conceptual Entity Model: The aim of conceptual model is to fix the meaning of terms and concepts used by domain experts, through entities and their relationships. A Conceptual Entity Model is hierarchically organized into domains and sub-domains.
Entity Designer: is the graphical editor of your applications Conceptual Entity Model. It is made with DSL technology and thus is fully integrated with Visual Studio environment.
EntityManager: is the runtime component that manages the in memory data and implements a rich and powerful relational data management API. Programming with this component is done directly against the conceptual model, no SQL is required.
Domain: is the hierarchical unit of organization for the Conceptual Model. Each domain is physically represented by a .net namespace. For example the conceptual model for AdventureWorks database is organized into 3 sub domains: AdventureWorks.Sales, AdventureWorks.Production and AdventureWorks.HumanResources.
Schema: For practical reasons the Conceptual Model is cut into independently editable parts (files). Each part is called a Schema. A Schema can contain entities, relations, entity references, composite types, enumerations and database enumerations. Each Schema belongs to at most one domain or sub-domain.
In the above schema we can see an entity Person, a relation ParentChild, a composite type Address, a database enumeration State and two enumerations ParentType and Place.
The entity Person has three properties Name, Birthday and Addresses. Name and Birthday have respectively a simple .net type String and DateTime, Addresses is a multi-value property of a composite type Address.
The composite type Address has five properties, three strings Street, City and Zip, a enumeration Place with type Place and a database enumeration State of type State. The
The property Place can take two values Home or Work and is an AccessKey. The values for State will be defined by the database entries.
The ParentChild relation is a many to many relation between persons. This relation has two ends a Parent end and a Child end, and a property ParentRole of type ParentType.
The property ParentRole can take two values Father or Mother.
Entity: is the building block of the Conceptual Model. An entity has a distinct, separate existence. An entity is Identifiable. Each entity is defined by a name (unique in the domain) and has an identifier (single or multi-part) and properties. Each property can have a simple (scalar, Enum, DatabaseEnum) or a composite type. Each property can have a single or multiple values. Properties can also be time dependant. Moreover entities have attributes that enable you to configure physical mappings with the persistent storage and/or special behaviors such as Triggers, Validators and UpdateHistory.
Entities can be thought of as nouns. Some examples: Product, Customer, Employee, Department...
Relation: represents a relation between two entities or relation ends. Each relation is defined by a name (unique in the domain). Each relation end has a Role, Cardinality and a Container attribute. Roles are used to map more closely with business terminology and/or to distinguish related entities if they are of the same type, as in reflexive relations. Cardinality is used to specify the one to one, the one to many or the many to many character of the relation. Relation ends, set to be Container, represent a strong type of relationship. The Container attribute modifies entity behavior in two ways. First while deleting a container end entity all related entities are automatically deleted. Second while loading graphs of data, all entities related to a container end are automatically loaded each time the container end entity is loaded.
Relations can have properties. Each property can have a simple (scalar, Enum, DatabaseEnum) or a composite type and a single value.
Moreover relations have attributes that enable you to configure physical mappings with the persistent storage and/or special behaviors such as Triggers and Validators.
Relations can be thought of as verbs such as WorksFor relation between Employee and Department entities.
CompositeType: is a set of properties that are naturally tied together and as such can be reused. Each composite type is defined by a name (unique in the domain). For example, we can define a composite type Address which is composed of properties: Street, City and ZipCode. We can then have two properties ShippingAddress and BillingAddress of type Address on an Order entity.
Enum: is a simply a .net enumeration, a mapping between integer values and names. An Enum is defined by a name (unique in the domain). For example, we can define an Enum Color composed of five colors Red, Green, Blue, Yellow and Black. We can then have two properties BackColor and ForeColor of type Color.
DatabaseEnum: is logically an Enum but with values defined in a database. A DatabaseEnum can have different fields, such as Code, Name and Description. A DatabaseEnum is defined by a name (unique in the domain). Not to large, quasi-constant, lists such as Country or City are appropriate candidates. For example, we can define a DatabaseEnum Country composed of two fields an integer CountryCode and a string CountryName. We can then have a property Country of type Country.
Property: Properties are used in defining entities and relations. Each entity or relation is composed of a set of properties. Each property has, among other attributes, a name, type and multiplicity.
The name must be unique per entity or relation. The type can be any simple .net type (numeric, string, date, boolean) or a CompositeType, an Enum or a DatabaseEnum. The multiplicity of a property can be one of the following:
- Simple: the property has a single value.
- Multiple: the property has multiple values determined by a key (AccesKey) unique per value.
- Temporal: the property is time dependent. It's like a multiple using time as key.
- Periodic: like temporal but with two keys, a start date and an end date.
Moreover properties have attributes that enable you to configure physical mappings with the persistent storage and/or special behaviors such as Default Value, Nullable, computed expression and Identifier or Validators.
- Default Value: is used to fill property value when new Entity instance is created.
- Nullable: If a property is nullable you can set it to a .net null value. While storing a .net DBNull value will be stored. If a property is not nullable, an exception will be raised if the application tries to set its value to null.
- Expression: an expression can be used to automatically compute the property value depending on other properties of the same entity. The syntax is the same as .net DataSet expressions.
- Identifier: can take one of the following values: Identifier, Unique, None.
- Identifier value means that the property participates in the identifier of the entity (which can be single or multi-part).
- Unique value, in case of an entity property means that its value must be unique for all entities, in case of a relation property means that the value participates in the unique constraint that acts on the relation ends with cardinality other than one. This feature enables you to create temporal relations (relation depending on time, valid for a given date) just by adding a time valued property with a unique attribute to a relation.
Multiplicity: this attribute specifies the multiplicity of values of property and can take one of the following values: Simple, Multiple, Temporal and Periodic. With a Simple multiplicity a property can have a single value. With the other options a property can have multiple values depending on a given AccesKey. With a Temporal multiplicity the access key's type is .net DateTime type. With a Periodic multiplicity the access key is a double key formed by two DateTimes, a startDate and an endDate.
AccesKey: this attribute specifies which properties of a CompositeType define the key values for Multiple, Temporal or Periodic properties.
Cardinality: this attribute specifies the one to one, the one to many or the many to many character of a relation end. Each relation having two relation ends corresponding to each entity being related.
Container: this attribute specifies a special behavior while loading or deleting entities. While loading an entity graph, all entities related to an entity having Container attribute set to true will be automatically and recursively loaded. While deleting an entity participating in a relation with Container attribute set to true, all related entities will be automatically and recursively deleted.
Role: Each relation relates two entities. Each entity in a relation is called a relation end. Each relation end has among other attributes a Type and a Role. By default the Role of a relation end equals its Type. You can use another value to match more closely with business terminology. Another Raison d'être for this attribute is distinguish related ends when they are of the same type as in reflexive relations. For example in the IsParent relation between two Person entities, one end acts as a parent the other as a child, thus two roles, Parent and Child that match better the domain of discourse help distinguish the two ends in the relation.
EntityReference: is used when you need to relate two entities of Conceptual Model that are not in the same Shema. In this case you must first create in one of the schemas an EntityReference that references the entity in the other schema, and then you can define your relation between this entity EntityReference and the appropriate entity.
Where To go from here?
You can continue getting acquainted with Aspectize DAL Technology features, tools and terminology by reading Entity Designer Overview, Entity Manager Overview and Terminology.
Or you can jump start your Aspectize experience by following our Quick Start Tutorial.