Changes for page The EOModel

Summary

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

Details

Page properties

Content

...	...	@@ -1,3 +1,11 @@
	1	+{{info}}
	2	+
	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	+{{/info}}
	6	+
	7	+{{toc}}{{/toc}}
	8	+
1	1	= The EOModel =
2	2
3	3	While it may seem obvious, data modeling is perhaps the most important phase of WebObjects application development. Data models form the foundation of your business logic and business logic forms the core of your application. Good business logic is essential to building effective applications, so it follows that good data models are essential to the success of the applications you build. Most importantly, data modeling plays a crucial role in object-relational mapping, the process in which database records are transposed into Java objects.
...	...	@@ -11,19 +11,19 @@
11	11	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.
12	12
13	13	WebObjects provides you with a great tool for object-relational mapping called EOModeler. It allows you to
14		-■ build data models either from scratch or by analyzing preexisting data sources using reverse engineering
15		-■ add and customize entities (tables) and attributes (columns)
16		-■ form relationships between entities
	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
17	17	■ form relationships across multiple models
18		-■ generate SQL from a model to create or update a data-source schema based on the model
19		-■ generate Java classes from a model in which you can add custom business logic
20		-■ use stored procedures within data 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
21	21	■ graphically build fetch specifications for retrieving data
22		-■ flatten attributes and relationships
23		-■ define derived attributes
24		-■ build database queries in raw SQL
	30	+■ flatten attributes and relationships
	31	+■ define derived attributes
	32	+■ build database queries in raw SQL
25	25
26		-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.
	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.
27	27
28	28	== Entities ==
29	29
...	...	@@ -92,14 +92,14 @@
92	92	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.
93	93	The possible value types for numeric attributes are as follows(note case):
94	94
95		-■ b—java.lang.Byte
96		-■ s—java.lang.Short
97		-■ i—java.lang.Integer
98		-■ l—java.lang.Long
99		-■ f—java.lang.Float
100		-■ d—java.lang.Double
101		-■ B—java.math.BigDecimal
102		-■ c—java.lang.Boolean
	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
103	103
104	104	== Prototypes ==
105	105
...	...	@@ -112,7 +112,7 @@
112	112	~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.
113	113	2. An entity named EOPrototypes.
114	114
115		-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.
	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.
116	116
117	117	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.
118	118
...	...	@@ -120,13 +120,13 @@
120	120
121	121	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:
122	122
123		-■ to-one relationship—for each source record, there is exactly one corresponding destination record
124		-■ to-many relationship—for each source record, there may be zero, one, or more corresponding destination
	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
125	125	records
126	126
127	127	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.
128	128
129		-The construction of a relationship requires that you designate at least one attribute in each entity as a relationship key.
	137	+The construction of a relationship requires that you designate at least one attribute in each entity as a relationship key.
130	130
131	131	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.
132	132
...	...	@@ -146,22 +146,22 @@
146	146
147	147	=== Flattened Relations ===
148	148
149		-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.
	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.
150	150
151	151	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.
152	152	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.
153	153
154		-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.
	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.
155	155
156	156	Therefore, you should use flattened attributes only in the following cases:
157	157
158	158	■ 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.
159		-■ If your application is read-only.
	167	+■ If your application is read-only.
160	160	■ If you're using vertical inheritance mapping. See "Vertical Mapping" (page 69).
161	161
162	162	=== Reflexive Relationships ===
163	163
164		-A unique kind of relationship is the reflexive relationship—a relationship that shares the same source and destination entity. Reflexive relationships are important when modeling data in which an instance of an entity points to another instance of the same entity.
	172	+A unique kind of relationship is the reflexive relationship~-~--a relationship that shares the same source and destination entity. Reflexive relationships are important when modeling data in which an instance of an entity points to another instance of the same entity.
165	165
166	166	For example, to show who a given person reports to, you could create a separate manager entity. It would be easier, however, to just create a reflexive relationship. The managerID attribute is the relationship's source key whereas employeeID is the relationship's destination key. Where a person's managerID is the employeeID of another employee object, the first employee reports to the second. If an employee doesn't have a manager, the value for the managerID attribute is null in that employee's record.
167	167
...	...	@@ -195,7 +195,7 @@
195	195
196	196	Relationships can be compound, meaning that they can consist of multiple pairs of connected attributes. You can specify additional pairs of attributes only in the Relationship Inspector. Simply select a second source attribute and a second destination attribute and click Connect a second time.
197	197
198		-A to-one relationship from one foreign key to a primary key must always have exactly one row in the destination entity—if this isn't guaranteed to be the case, use a to-many relationship. This rule doesn't apply to a foreign key to primary key relationship where a null value for the foreign key in the source row indicates that no row exists in the destination.
	206	+A to-one relationship from one foreign key to a primary key must always have exactly one row in the destination entity~-~--if this isn't guaranteed to be the case, use a to-many relationship. This rule doesn't apply to a foreign key to primary key relationship where a null value for the foreign key in the source row indicates that no row exists in the destination.
199	199
200	200	To-one relationships must join on the complete primary key of the destination entity.
201	201
...	...	@@ -209,10 +209,38 @@
209	209
210	210	== Fetch Specs in Model ==
211	211
	220	+After you create and configure entities in EOModeler, you can also use it to build queries on those entities called fetch specifications. A fetch specification (a com.webobjects.eocontrol.EOFetchSpecification object) is the object Enterprise Objects uses to get data from a data source.
	221	+
	222	+Each fetch specification can contain a qualifier, which fetches only those rows that meet the criteria in the qualifier. A fetch specification allows you to specify a sort ordering to sort the rows of data returned. A fetch specification can also have other characteristics, as discussed in this chapter.
	223	+
	224	+Fetch specifications you build in EOModeler are referred to as named fetch specifications. To use a named fetch specification requires that you get hold of the model object in which the fetch specification exists. The code in Listing 7-1 retrieves a fetch specification called "MyFetch" in an entity named "Listing" by looking for it in all the models in the application's default model group.
	225	+
	226	+If you define a qualifier like this:
	227	+
	228	+{{code}}
	229	+(askingPrice < $askingPrice) and (bedrooms = $bedrooms) and (bathrooms = $bathrooms)
	230	+{{/code}}
	231	+
	232	+then the qualifier variables are replaced by 500000 (askingPrice), 4 (bedrooms), and 3 (bathrooms).
	233	+
	234	+{{code}}
	235	+
	236	+EOModelGroup modelGroup = EOModelGroup.defaultGroup();
	237	+EOFetchSpecification fs = modelGroup.fetchSpecificationNamed("MyFetch", "Listing");
	238	+fs = fs.fetchSpecificationWithQualifierBindings(dictionary);
	239	+NSMutableDictionary dictionary = new NSMutableDictionary();
	240	+dictionary.takeValueForKey("500000", "askingPrice");
	241	+dictionary.takeValueForKey("4", "bedrooms");
	242	+dictionary.takeValueForKey("3", "bathrooms");
	243	+
	244	+{{/code}}
	245	+
	246	+== Stored procedures ==
	247	+
212	212	You can set up an EOModel so that Enterprise Objects automatically invokes a stored procedure for these operations on an entity:
213	213
214		-Insert to insert a new object into an entity
215		-Delete to delete an object from an entity
	250	+Insert to insert a new object into an entity
	251	+Delete to delete an object from an entity
216	216	Fetch All to fetch all objects in an entity
217	217	Fetch w/ PKto fetch the object in an entity with a particular primary key
218	218	Get PK to generate a new primary key for an entity
...	...	@@ -243,7 +243,7 @@
243	243
244	244	== EO Inheritance ==
245	245
246		-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.
	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.
247	247
248	248	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.
249	249
...	...	@@ -285,7 +285,7 @@
285	285
286	286	==== Disadvantages of Horizontal Mapping ====
287	287
288		-Problems may occur when attributes need to be added to the Person superclass. The number of tables that need to be altered is equal to the number of subclasses—the more subclasses you have, the more effort is required to maintain the superclass.
	324	+Problems may occur when attributes need to be added to the Person superclass. The number of tables that need to be altered is equal to the number of subclasses~-~--the more subclasses you have, the more effort is required to maintain the superclass.
289	289
290	290	If, for example, you need to add an attribute called middleName to the Person class, you then need to alter its subclasses, Employee and Customer. So if you have deep inheritance hierarchies or many subclasses, this can be tedious. However, if table maintenance happens far less often than fetches, this might be a viable approach for your application.
291	291
...	...	@@ -304,8 +304,11 @@
304	304	==== Disadvantages of Single-Table Mapping ====
305	305
306	306	Single-table mapping results in tables that have columns for all of the attributes of each entity in the inheritance hierarchy. It also results in many null row values. While these aren't really disadvantages, they may conflict with some database design philosophies.
307		-
308	308
	344	+=== Using Inheritance in Entity Modeler ===
	345	+
	346	+To use Inheritance in your model, you first need to create your base entity. When done, right-click on the entity and select Subclass. A dialog will appear and will ask you to specify which kind of Inheritance you want to use, which entity is the parent and the name of the new (child) entity. When selecting Vertical or Single-Table Inheritance, you can also specify the qualifier (type = XX) in that dialog (you can do that part later too).
	347	+
309	309	== EOGenerator ==
310	310
311	311	== Handling Blob Data ==