Network Model

1 APPENDIXDN etworkModelIn the relational Model , the data and the relationships among data are representedby a collection of tables. The Network Model differs from the relational Model inthat data are represented by collections ofrecords, and relationships among dataare represented this chapter we illustrate our concepts using a bank enterprise with theschema shown in Figure ConceptsA Network database consists of a collection of records connected to one anotherthrough links. A record is in many respects similar to an entity in record is a collection of fields (attributes), each of which contains only onedata value. A link is an association between precisely two records. Thus, a linkcan be viewed as a restricted (binary) form of relationship in the sense of an illustration, consider a database representing acustomer-accountrela-tionship in a banking system.

2 There are two record types, saw earlier, we can define thecustomerrecord type, using Pascal-like notation:typecustomer=recordcustomername :string;customerstreet:string;customerci ty:string;endTheaccountrecord type can be defined astypeaccount=recordaccountnumber:string ;balance: integer;endThe sample database in Figure shows that Hayes has account A-102, Johnsonhas accounts A-101 and A-201, and Turner has account DNetwork ModelFigure DiagramsAdata-structure diagramis a schema representing the design of a Network a diagram consists of two basic , which correspond to record , which correspond to linksA data-structure diagram serves the same purpose as anE-Rdiagram; namely, itspecifies the overall logical structure of the database. So that you will understandhow such diagrams are structured, we shall show how to transformE-Rdiagramsinto their corresponding data-structure Binary RelationshipConsider theE-Rdiagram of Figure , consisting of two entity sets,customerandaccount, related through a binary, many-to-many relationshipdepositor,withno descriptive attributes.

3 This diagram specifies that a customer may have sev-eral accounts, and that an account may belong to several different corresponding data-structure diagram appears in Figure The recordtypecustomercorresponds to the entity setcustomer. It includes three fields Figure diagram and its corresponding data-structure Diagrams3 Figure data-structure ,customerstreet,andcustomercity as defined in Section Simi-larly,accountis the record type corresponding to the entity two fieldsaccountnumberandbalance. Finally, the relationshipdepositorhasbeen replaced with the relationshipdepositoris many to many. If the relationshipdepositorwereone to many fromcustomertoaccount, then the linkdepositorwould have an arrowpointing tocustomerrecord type (Figure ). Similarly, if the relationshipdeposi-torwere one to one, then the linkdepositorwould have two arrows: one pointing toaccountrecord type and one pointing tocustomerrecord type (Figure ).

4 Since,in theE-Rdiagram of Figure , thedepositorrelationship is many to many, wedraw no arrows on the linkdepositorin Figure database corresponding to the described schema may thus contain a num-ber ofcustomerrecords linked to a number ofaccountrecords. A sample databasecorresponding to the data-structure diagram of Figure appears in Figure the relationship is many to many, we show that Johnson has accounts A-101and A-201 and that account A-201 is owned by both Johnson and Smith. A sampledatabase corresponding to the data-structure diagram of Figure is depictedin Figure Since the relationship is one to many fromcustomertoaccount,acustomer may have more than one account, as Johnson does she owns bothA-101 and A-201. Anaccount, however, cannot belong to more than one customer,and the database observes this restriction.

5 Finally, a sample database correspond-ing to the data-structure diagram of Figure is shown in Figure Since therelationship is one to one, an account can be owned by precisely one customer,and a customer can have only one account; the sample database follows database corresponding to diagram of Figure DNetwork ModelFigure database corresponding to diagram of Figure a relationship includes descriptive attributes, the transformation from anE-Rdiagram to a data-structure diagram is more complicated. A link cannotcontain any data value, so a new record type needs to be created and links needto be theE-Rdiagram of Figure Suppose that we add the attributeaccessdateto the relationshipdepositor, to denote the most recent time that acustomer accessed the account.

6 This newly derivedE-Rdiagram appears in Fig-ure To transform this diagram to a data-structure diagram, we entitiescustomerandaccountwith record typescustomerandaccount, a new record typeaccessdatewith a single field to represent the the following many-to-one links:Figure diagram and its corresponding Network Diagrams5 Figure database corresponding to diagram of Figure customerdatefrom theaccessdaterecord type to thecustomerrecord type accountdatefrom theaccessdaterecord type to theaccountrecord typeThe resulting data-structure diagram appears in Figure instance of a database corresponding to the described schema appears inFigure It shows that: Account A-201 is held by Johnson alone, and was last accessed by her on 17 June. Account A-305 is held by Turner alone, and was last accessed by him on 28 May.

7 Account A-102 is held by both Hayes and Johnson. Hayes accessed it last on10 June, and Johnson accessed it last on 24 General RelationshipsConsider theE-Rdiagram of Figure , which consists of three entity sets account,customer,andbranch related through the general relationshipCABwithno descriptive a link can connect precisely two different record types, we need toconnect these three record types through a new record type that is linked to eachof them transform theE-Rdiagram of Figure to a Network data-structurediagram, we need to do the entity setsaccount,customer,andbranchwith record typesaccount,customer,andbranch, a new record typeRlinkthat may either have no fields or have a singlefield containing a unique identifier. The system supplies this identifier, andthe application program does not use it directly.

8 This new type of record issometimes referred to as adummy(orlinkorjunction) record DNetwork ModelFigure diagram and its corresponding data-structure the following many-to-one links: CustRlnkfromRlinkrecord type tocustomerrecord type AcctRlnkfromRlinkrecord type toaccountrecord type BrncRlnkfromRlinkrecord type tobranchrecord typeThe resulting data-structure diagram appears in Figure sample database corresponding to the described schema appears in Fig-ure It shows that Hayes has account A-102 in the Perryridge branch, Johnsonhas accounts A-101 and A-201 in the Downtown and Perryridge branches, re-spectively, and Turner has account A-305 in the Round Hill can extend this technique in a straightforward manner to deal with rela-tionships that span more than three entity sets.

9 We create a many-to-one link fromtheRlinkrecord to the record types corresponding to each entity set involved inthe relationship. We can also extend the technique to deal with a general rela-tionship that has descriptive attributes. We need to add one field to the dummyrecord type for each descriptive DBTG CODASYL Model7 Figure database corresponding to diagram of Figure DBTG CODASYL ModelThe first database-standard specification, called theCODASYL DBTG1971 report,was written in the late 1960s by the Database Task Group. Since then, a numberof changes have been proposed many of which are reflected in our discussionconcerning Link RestrictionIn theDBTG Model , only many-to-one links can be used. Many-to-many links aredisallowed to simplify the implementation.

10 We represent one-to-one links using amany-to-one link. These restrictions imply that the various algorithms of for transforming anE-Rdiagram to a data-structure diagram must be a binary relationship that is either one to many or one to one. Inthis case, the transformation algorithm defined in Section can be applieddirectly. Thus, for our customer-account database, if thedepositorrelationship isone to many with no descriptive attributes, then the appropriate data-structurediagram is as shown in Figure If the relationship has a descriptive attribute(for example,access-date), then the appropriate data-structure diagram is as shownin Figure thedepositorrelationship, however, is many to many, then our transforma-tion algorithm must be refined; if the relationship has no descriptive attributes(Figure ), then this algorithm must be the entity setscustomerandaccountwith record typescustomerandaccount, a new dummy record type,Rlink, that may either have no fields orhave a single field containing an externally defined unique the following two many-to-one links:8 Appendix DNetwork ModelFigure data-structure diagrams.