| OCR Text |
Show 2.3 Why POS? One p ro l>lem about OODBMSs is t hat a relat ively small change in t he data model may require subs t a nt ia l changes in the a rchi tecture of a d a tabase system , e .g ., to impl eme nt mctaclasses iu an object-oriented dc1.ta mo del, a number of d ifferen t components of the system will have to be changed [12]. One way to address this prol >lem is to def-ine a storage- lC'vc] SIJhsystPm (POS) as a kernel to Stl pport a l<nge ,,t lmlwr of d i flerf~nt object-oriented data models e .g ., Mneme [17] supports both Small talk-80 and 1\llodul a-3. Difl'erent applicat ions can use a common POS by embeddin g a ny necessary mappi ng, like tranlat ing appli cation object to POS obj<'ct, in a separate layer or in Lhe app li cation itself. An OODBMS t hen becomes <t POS with a DBMS. 2.4 Features of POSs A compre he nsive list of issues that most POSs m ust address is p rovided b elow. After the list of issues, a description fo llows of a number of OODBMSs and POSs, ct tH.:l how they ha ndle t hese isst1cs . In genera l, a ll POSs manage a segment of' memory representing an object , provide some kind of identifier to this segment, <tJJd hct\' (' so!llC' support for Jn<t.11ipulati ng tbe res ul ting o bject. !11 ctcld iLion , some of llwJll pmv i d(~ s t!pport fur 11 avigation and sc:bema. evolutio n. Most POSs recogn1ze Llw need for distribution. 2.4.1 Memory Management TI 1C'r(' arc two ways iu which POSs p rovi cl (-' nwnwry management. One is t hrough <1 procedural i nt~c' rl~1cc to the store th at manages mem ory and tbe other is by I11C!Jlpillg LlJ(' Jlwmory into Lhe applicat ion's add ress space [19, l LI]. vVhen an o bject is loaded into a process' add ress space from tbe disk, t be object references ins ide this object must correspond to meaningful virtual memory addresses. This can |
