Changes for page The EOModel

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -1,10 +1,8 @@
1	1	{{info}}
2		-
3	3	Work in progress! Right now, most of the text is coming from Apple's documentation. We need to change that, and add Wonder and WOLips specific information.
4		-
5	5	{{/info}}
6	6
7		-{{toc}}{{/toc}}
	5	+{{toc/}}
8	8
9	9	= The EOModel =
10	10
...	...	@@ -19,19 +19,19 @@
19	19	Data models in Enterprise Objects reflect the earliest decisions about what data users see and how they are allowed to interact with data. This is because an important part of data modeling is deciding which entities and attributes are visible to clients and editable by clients. So by including data modeling as an early part of the design process, you can simplify future implementation details.
20	20
21	21	WebObjects provides you with a great tool for object-relational mapping called EOModeler. It allows you to
22		-■ build data models either from scratch or by analyzing preexisting data sources using reverse engineering
23		-■ add and customize entities (tables) and attributes (columns)
24		-■ form relationships between entities
25		-■ form relationships across multiple models
26		-■ generate SQL from a model to create or update a data-source schema based on the model
27		-■ generate Java classes from a model in which you can add custom business logic
28		-■ use stored procedures within data models
29		-■ graphically build fetch specifications for retrieving data
30		-■ flatten attributes and relationships
31		-■ define derived attributes
32		-■ build database queries in raw SQL
	20	+ ■ build data models either from scratch or by analyzing preexisting data sources using reverse engineering
	21	+ ■ add and customize entities (tables) and attributes (columns)
	22	+ ■ form relationships between entities
	23	+ ■ form relationships across multiple models
	24	+ ■ generate SQL from a model to create or update a data-source schema based on the model
	25	+ ■ generate Java classes from a model in which you can add custom business logic
	26	+ ■ use stored procedures within data models
	27	+ ■ graphically build fetch specifications for retrieving data
	28	+ ■ flatten attributes and relationships
	29	+ ■ define derived attributes
	30	+ ■ build database queries in raw SQL
33	33
34		-In an Entity-Relationship model, distinguishable things are known as entities, each entity is defined by its component attributes, and the affiliations, or relationships between entities, are identified (together, attributes and relationships are known as properties). From these three simple modeling objects~-~-entities, attributes, and relationships~-~-arbitrarily complex systems can be modeled.
	32	+In an Entity-Relationship model, distinguishable things are known as entities, each entity is defined by its component attributes, and the affiliations, or relationships between entities, are identified (together, attributes and relationships are known as properties). From these three simple modeling objects~-~-(% style="text-decoration: line-through;" %)entities, attributes, and relationships(%%)~-~-arbitrarily complex systems can be modeled.
35	35
36	36	== Entities ==
37	37
...	...	@@ -44,31 +44,31 @@
44	44	=== Entity characteristics ===
45	45
46	46	Class Name
47		-The name of the class that corresponds to the entity. If you don't define a custom enterprise object class for an entity, the class name defaults to EOGenericRecord. You should use a fully qualified name but this isn't strictly required.
	45	+ The name of the class that corresponds to the entity. If you don't define a custom enterprise object class for an entity, the class name defaults to EOGenericRecord. You should use a fully qualified name but this isn't strictly required.
48	48
49	49	Client-Side Class Name
50		-The name of the class that corresponds to the entity in the client side of a three-tier WebObjects Java Client application. If you don't define a client-side class, Enterprise Objects looks for a class in the client with the same name as the server-side enterprise object class. If no such class exists on the client, it uses EOGenericRecord. You should use a fully qualified name but this isn't strictly required.
	48	+ The name of the class that corresponds to the entity in the client side of a three-tier WebObjects Java Client application. If you don't define a client-side class, Enterprise Objects looks for a class in the client with the same name as the server-side enterprise object class. If no such class exists on the client, it uses EOGenericRecord. You should use a fully qualified name but this isn't strictly required.
51	51
52	52	External Query
53		-Any valid SQL statement that you want executed when unqualified fetches are performed on the entity.
	51	+ Any valid SQL statement that you want executed when unqualified fetches are performed on the entity.
54	54
55	55	Name
56		-The name your application uses for the entity. By default, EOModeler supplies a name based on the name of the corresponding table in the data source.
	54	+ The name your application uses for the entity. By default, EOModeler supplies a name based on the name of the corresponding table in the data source.
57	57
58	58	Open Entity
59		-Adds a column with an icon which you can double-click to display an entity's attributes.
	57	+ Adds a column with an icon which you can double-click to display an entity's attributes.
60	60
61	61	Parent
62		-Specifies an entity's parent when using inheritance.
	60	+ Specifies an entity's parent when using inheritance.
63	63
64	64	Qualifier
65		-Specifies a restricting qualifier that is added to every fetch specification performed on the entity. Used when modeling inheritance hierarchies.
	63	+ Specifies a restricting qualifier that is added to every fetch specification performed on the entity. Used when modeling inheritance hierarchies.
66	66
67	67	Read Only
68		-Specifies if the entity is read-only.
	66	+ Specifies if the entity is read-only.
69	69
70	70	Table
71		-The name of the table in the data source that corresponds to the entity
	69	+ The name of the table in the data source that corresponds to the entity
72	72
73	73	=== Advanced Entity Inspector ===
74	74
...	...	@@ -95,32 +95,32 @@
95	95	== Value Types ==
96	96
97	97	Value Type
98		-When you choose a value class for a particular attribute, you sometimes do not provide Enterprise Objects with all the information the JDBC adaptor needs to negotiate with the data source.
	96	+ When you choose a value class for a particular attribute, you sometimes do not provide Enterprise Objects with all the information the JDBC adaptor needs to negotiate with the data source.
99	99
100	100	For example, when you specify Number as the value class for a particular attribute, you are telling Enterprise Objects to use java.lang.Number, which is an abstract class. This is where the value type characteristic steps in. It specifies the exact class an attribute should map to.
101		-The possible value types for numeric attributes are as follows(note case):
	99	+ The possible value types for numeric attributes are as follows(note case):
102	102
103	103	■ b~-~--java.lang.Byte
104		-■ s~-~--java.lang.Short
105		-■ i~-~--java.lang.Integer
106		-■ l~-~--java.lang.Long
107		-■ f~-~--java.lang.Float
108		-■ d~-~--java.lang.Double
109		-■ B~-~--java.math.BigDecimal
110		-■ c~-~--java.lang.Boolean
	102	+ ■ s~-~--java.lang.Short
	103	+ ■ i~-~--java.lang.Integer
	104	+ ■ l~-~--java.lang.Long
	105	+ ■ f~-~--java.lang.Float
	106	+ ■ d~-~--java.lang.Double
	107	+ ■ B~-~--java.math.BigDecimal
	108	+ ■ c~-~--java.lang.Boolean
111	111
112	112	== Prototypes ==
113	113
114	114	To make creating models easier, EOModeler supports prototype attributes. These are special attributes from which other attributes derive their settings. A prototype can specify any of the characteristics you normally define for an attribute. When you create an attribute, you can associate it with one of these prototypes, and the attribute's characteristics are then set from the prototype definition.
115	115
116		-For example, you can create a prototype attribute called lastModified whose value class is Date, whose external type is datetime, and which corresponds to a column named LAST//MODIFIED. Then, when you create other entities, you can create an attribute and associate it with this prototype and the prototype's values are copied in to the new attribute. You can then change any values in or add values to the new attribute. Any value that is inherited from the prototype that you don't override uses the value defined in the prototype..//
	114	+For example, you can create a prototype attribute called lastModified whose value class is Date, whose external type is datetime, and which corresponds to a column named LAST_MODIFIED. Then, when you create other entities, you can create an attribute and associate it with this prototype and the prototype's values are copied in to the new attribute. You can then change any values in or add values to the new attribute. Any value that is inherited from the prototype that you don't override uses the value defined in the prototype..
117	117
118	118	Creating Prototype Attributes
119		-The prototypes you can assign to attributes can come from two places:
120		-~1. An entity named EOAdaptorNamePrototypes, where AdaptorName is the name of the adaptor for your model. WebObjects 5.2 includes an adaptor for JDBC data sources and an adaptor for JNDI data sources. So you can create a prototype entity called either EOJDBCPrototypes or EOJNDIPrototypes, depending on the adaptor you use.
121		-2. An entity named EOPrototypes.
	117	+ The prototypes you can assign to attributes can come from two places:
	118	+ ~1. An entity named EOAdaptorNamePrototypes, where AdaptorName is the name of the adaptor for your model. WebObjects 5.2 includes an adaptor for JDBC data sources and an adaptor for JNDI data sources. So you can create a prototype entity called either EOJDBCPrototypes or EOJNDIPrototypes, depending on the adaptor you use.
	119	+ 2. An entity named EOPrototypes.
122	122
123		-To create a prototype attribute, first create a prototype entity~-~-an entity named either EOAdaptorNamePrototypes or EOPrototypes~-~-and add an attribute to it. Figure 3-3 shows an attribute in a prototype entity. It shows all the values that prototype attributes can define: column name, value class, external type, and value type.
	121	+To create a prototype attribute, first create a prototype entity~-~-(% style="text-decoration: line-through;" %)an entity named either EOAdaptorNamePrototypes or EOPrototypes(%%)~-~-and add an attribute to it. Figure 3-3 shows an attribute in a prototype entity. It shows all the values that prototype attributes can define: column name, value class, external type, and value type.
124	124
125	125	To assign a prototype attribute to an attribute, reveal the Prototype column in table mode, and select a prototype attribute from the pop-up menu. The prototype attributes that appear in the pop-up list in the Prototype column include prototype attributes defined in any entity in any model in the application's model group, which includes the current model.
126	126
...	...	@@ -129,8 +129,8 @@
129	129	Every relationship has a cardinality. The cardinality defines how many destination records can potentially resolve the relationship. In relational database systems, there are generally two cardinalities:
130	130
131	131	■ to-one relationship~-~--for each source record, there is exactly one corresponding destination record
132		-■ to-many relationship~-~--for each source record, there may be zero, one, or more corresponding destination
133		-records
	130	+ ■ to-many relationship~-~--for each source record, there may be zero, one, or more corresponding destination
	131	+ records
134	134
135	135	An employeeDepartment relationship is an example of a to-one relationship: An employee can be associated with only one department in a company. An Employee entity might also be associated with a Project entity. In this case, there would be a to-many relationship from Employee to Project called projects since an Employee can have many projects.
136	136
...	...	@@ -139,8 +139,8 @@
139	139	There are some general guidelines when choosing which attributes to use as relationship keys. In to-one relationships, the destination key must be a primary key in the destination entity. In to-many relationships, the destination key is usually a foreign key in the destination entity (which is most often a copy of the source entity's primary key). The source key or foreign key should emulate the destination key in that the data types must be the same and the names should be similar.
140	140
141	141	When you use relationship keys to express an affiliation between two entities, keep in mind these general rules:
142		-■ For to-one relationships, the source attribute is a foreign key in the source entity while the destination key is the primary key of the destination entity.
143		-■ For to-many relationships, the source attribute is the primary key in the source entity (but it can also be a foreign key in the source entity) while the destination key is a foreign key of the destination entity.
	140	+ ■ For to-one relationships, the source attribute is a foreign key in the source entity while the destination key is the primary key of the destination entity.
	141	+ ■ For to-many relationships, the source attribute is the primary key in the source entity (but it can also be a foreign key in the source entity) while the destination key is a foreign key of the destination entity.
144	144
145	145	If you have consistency checking enabled in EOModeler, it warns you if any to-one relationships in your model have destination keys that are not primary keys.
146	146
...	...	@@ -157,7 +157,7 @@
157	157	A flattened attribute is a special kind of attribute that you effectively add from one entity to another by traversing a relationship. When you form a to-one relationship between two entities (such as Person and PersonPhoto), you can add attributes from the destination table to the source table. For example, you can add a personPhoto attribute to the Person entity. This is called "flattening" an attribute and is equivalent to creating a joined column~-~--it allows you to create objects that extend across tables.
158	158
159	159	Flattening attributes is just another way to conceptually "add" an attribute from one entity to another. A generally better approach is to traverse the object graph directly through relationships. Enterprise Objects makes this easy by supporting the notion of key paths.
160		-The difference between flattening attributes and traversing the object graph (either programmatically or by using key paths) is that the values of flattened attributes are tied to the database rather than the object graph. If an enterprise object in the object graph changes, a flattened attribute can quickly get out of sync.
	158	+ The difference between flattening attributes and traversing the object graph (either programmatically or by using key paths) is that the values of flattened attributes are tied to the database rather than the object graph. If an enterprise object in the object graph changes, a flattened attribute can quickly get out of sync.
161	161
162	162	For example, suppose you flatten a departmentName attribute into an Employee object. If a user then changes an employee's department reference to a different department or changes the name of the department itself, the flattened attribute won't reflect the change until the changes in the object graph are committed to the database and the data is refetched (this is because flattened attributes are derived attributes~-~--see "Definition (Derived Attributes)" (page 38) for more details). However, if you're using key paths in this scenario, users see changes to data as soon as they happen in the object graph. This ensures that your application's view of the data remains internally consistent.
163	163
...	...	@@ -164,8 +164,8 @@
164	164	Therefore, you should use flattened attributes only in the following cases:
165	165
166	166	■ If you want to combine multiple tables joined by a one-to-one relationship to form a logical unit. For example, you might have employee data that's spread across multiple tables such as ADDRESS, BENEFITS, and so on. If you have no need to access these tables individually (that is, if you'd never need to create an Address object since the address data is always subsumed in the Employee object), then it makes sense to flatten attributes from those entities into the Employee entity.
167		-■ If your application is read-only.
168		-■ If you're using vertical inheritance mapping. See "Vertical Mapping" (page 69).
	165	+ ■ If your application is read-only.
	166	+ ■ If you're using vertical inheritance mapping. See "Vertical Mapping" (page 69).
169	169
170	170	=== Reflexive Relationships ===
171	171
...	...	@@ -190,10 +190,10 @@
190	190	==== Delete Rule ====
191	191
192	192	The options in the Delete Rule section specify what to do when the source object of a relationship is deleted. There are four options:
193		-■ **Nullify** disassociates all destination objects from the source object by removing references to them. So, when an Agent object is deleted, its related Customer objects are not deleted but the Customer objects' references to Agent are nullified (the entry in the join table is set to null).
194		-■ **Cascade** deletes all objects that are the destination of a relationship whose source is deleted. So, when an Agent object is deleted, all of its related Customer objects are also deleted.
195		-■ **Deny** refuses the deletion if a source object has any destination objects. So, if an Agent object has any Customer objects, deleting the Agent object is denied. In order for the deletion of the Agent object to succeed, its destination objects (Customer objects) must either be deleted or changed to something other than destination objects of the Agent object.
196		-■ **No Action** deletes the destination object but does not remove any back references to the source object. So, if a Customer object is deleted, its reference to its Agent object is not removed. Using this option may result in dangling references in the data source.
	191	+ ■ **Nullify** disassociates all destination objects from the source object by removing references to them. So, when an Agent object is deleted, its related Customer objects are not deleted but the Customer objects' references to Agent are nullified (the entry in the join table is set to null).
	192	+ ■ **Cascade** deletes all objects that are the destination of a relationship whose source is deleted. So, when an Agent object is deleted, all of its related Customer objects are also deleted.
	193	+ ■ **Deny** refuses the deletion if a source object has any destination objects. So, if an Agent object has any Customer objects, deleting the Agent object is denied. In order for the deletion of the Agent object to succeed, its destination objects (Customer objects) must either be deleted or changed to something other than destination objects of the Agent object.
	194	+ ■ **No Action** deletes the destination object but does not remove any back references to the source object. So, if a Customer object is deleted, its reference to its Agent object is not removed. Using this option may result in dangling references in the data source.
197	197
198	198	=== Tips ===
199	199
...	...	@@ -248,10 +248,10 @@
248	248	You can set up an EOModel so that Enterprise Objects automatically invokes a stored procedure for these operations on an entity:
249	249
250	250	**Insert** to insert a new object into an entity
251		-**Delete** to delete an object from an entity
252		-**Fetch All** to fetch all objects in an entity
253		-**Fetch w/ PK** to fetch the object in an entity with a particular primary key
254		-**Get PK** to generate a new primary key for an entity
	249	+ **Delete** to delete an object from an entity
	250	+ **Fetch All** to fetch all objects in an entity
	251	+ **Fetch w/ PK** to fetch the object in an entity with a particular primary key
	252	+ **Get PK** to generate a new primary key for an entity
255	255
256	256	The stored procedures you enter in the Stored Procedure Inspector must correspond to a stored procedure in the model. If you created the model from an existing data source and chose the Ask About Stored Procedures option in the wizard, stored procedures are already added to the model. If this is not the case, however, you can add stored procedures to the model using the Add Stored Procedure command from the Property menu.
257	257
...	...	@@ -279,7 +279,7 @@
279	279
280	280	== EO Inheritance ==
281	281
282		-One of the issues that may arise in designing your enterprise objects~-~-whether you're creating a schema from scratch or working with an existing database schema~-~-is the modeling of inheritance relationships.
	280	+One of the issues that may arise in designing your enterprise objects~-~-(% style="text-decoration: line-through;" %)whether you're creating a schema from scratch or working with an existing database schema(%%)~-~-is the modeling of inheritance relationships.
283	283
284	284	In object-oriented programming, it's natural to think of data in terms of inheritance. A Customer object, for example, naturally inherits certain characteristics from a Person object, such as name, address, and phone number. In inheritance hierarchies, the parent object or superclass is usually rather generic so that less generic subclasses of a related type can easily be added. So, in addition to the Customer object, a Client object also naturally derives from a Person object.
285	285
...	...	@@ -349,12 +349,44 @@
349	349
350	350	For many years, a tool called **EOGenerator** was used by many developers to use the Generation Gap Pattern on the Enterprise Objects. Since **EOGenerator** was using a ObjectiveC <-> Java that Apple killed in Mac OS X 10.5, a 100% Java tool, **Veogen**, was added to WOLips, so by default everyone is now using it.
351	351
352		-By using **Veogen**, when you create a new EO entity in your data model, two Java class will be generated, one called //EntityName.java, and the other EntityName.java. The class starting with the underscore will be regenerated every time you modify the entity in the model, if you want to change something in that class, you need to change the template. The class without the underscore is the place where you can add other variables or methods.//
	350	+By using **Veogen**, when you create a new EO entity in your data model, two Java class will be generated, one called _EntityName.java, and the other EntityName.java. The class starting with the underscore will be regenerated every time you modify the entity in the model, if you want to change something in that class, you need to change the template. The class without the underscore is the place where you can add other variables or methods.
353	353
354	354	== Handling Blob Data ==
355	355
356	356	== Connection Dictionary ==
357	357
	356	+In each EOModel, you can store one or many database configurations. A database configuration consists of the prototype selection for your database (MySQL, H2, etc.), the adaptor (99% of the time, it's JDBC), the URL (JDBC connection string), the username and password to connect to the datastore, the driver (JDBC driver name) and the name of the EOAdaptor plugin. You need to have at least one database configuration in your model so that you can use database migrations and reverse engineer a database to a model.
	357	+
	358	+When you launch your application, it will use the default database configuration from the model. An alternative to database configuration is to use properties in the Properties file to specify the connection dictionary. For example, for a H2 database, you can use a configuration like this:
	359	+
	360	+{{panel}}
	361	+dbConnectUserGLOBAL=
	362	+ dbConnectPasswordGLOBAL=
	363	+ dbConnectURLGLOBAL = jdbc:h2:file:~~/politimo
	364	+ dbConnectPluginGLOBAL = H2PlugIn
	365	+{{/panel}}
	366	+
	367	+Using the **GLOBAL** properties will apply the properties to all models in your application (and to models in your frameworks). You can also specify propertiers per model, with those properties:
	368	+
	369	+{{panel}}
	370	+[WO:MODEL_NAME].DBDriver
	371	+ [WO:MODEL_NAME].DBHostName
	372	+ [WO:MODEL_NAME].DBPassword
	373	+ [WO:MODEL_NAME].DBPlugin
	374	+ [WO:MODEL_NAME].DBURL
	375	+ [WO:MODEL_NAME].DBUser
	376	+{{/panel}}
	377	+
	378	+So if your EOModel is called **Politimo**, the properties will be:
	379	+
	380	+{{panel}}
	381	+Politimo.DBDriver =
	382	+Politimo.DBPassword =
	383	+Politimo.DBPlugin = H2PlugIn
	384	+ Politimo.DBURL = jdbc:h2:file:~~/politimo
	385	+ Politimo.DBUser =
	386	+{{/panel}}
	387	+
358	358	== Runtime Selection of the Connection Dictionary and Prototypes ==
359	359
360	360	== Debugging JDBC Connections and Jdbc2info ==