Object-relationship modelling

Object-Relationship Modelling (ORM) is a technique for designing or describing relational databases. The method was devised by Terry Halpin.

In ORM and related technologies each database table can be thought of as an object. It should be named singularly because a collection of rows of the database can be considered a collection. Consider this; each table will have one or more parent tables and likewise each table can have one or more child tables, that is to say the arrangement is very similar to a set of spokes protruding from the center. Each column in each parent table should be considered to be a property of the object table. This typically would be a read only property, but it is possible to have it also be read and write however the effects would cascade into any other table that was a child of the parent table, in other words, all sybling tables. Each child table can be considered a collection of one or more things.

Let's take an example. I will assume that we have three tables, one, the object table is the center item, it is a people table. It contains singular information about a person in it's rows. Each row would be aboue one and only one person and the columns could be things such as Surname, GivenName, NationalIdentity, Username, Password and so forth. Each of these would be mapped as a property.

Now, there is a table that is closely related and is parent to the person table and that is the company table. Assuming that a person may only work for one company at a given time it could be expressed that the company "owns" the person. Each column in the company table would become a property of the object table. To avoid name collisions it is common to prepend the table name to the property name when the object is created, i.e. Person.CompanyCity, Person.CompanyDomain so on and so forth.

Let's add to this the prospect of a child table. Ignoring the fact that it is possible for more then one person to live at a given address and that one person can have more then one address let us assume that an address has just one person living there, and that each person can have multiple addresses. So, you see that the multiple addresses becomes a collection of addresses for each person. Thus; Person.Address[0].StreetName, Person.Address[0].City.

Sometimes we get another type of relationship between tables which is a joining table. If a table is a mapper between two static objects, ie person(s) to address(es) and alternatively address(es) to person(s) then the relationship can be expressed as Person.Address[0].StreetName or a shorter notation could be devises Person.AddressStreetName.

For more information feel free to contact me at --Onesys 23:39, 26 Feb 2004 (UTC)

This article is a stub. You can help Wikipedia by expanding it.