A domain of discourse document is a file that involves a set of entities with particular variables of different data type ranges. The primary purpose of the document is to keep important details regarding the database scenario. For instance, it stores database information concerning entities and table relationship that defines the tables structures.
Adding information contained in the domain of discourse to the scenario description would complicate the information presented to the database. This approach would make the database details, for instance, hospital database to become ambiguous. Furthermore, the information included in the domain of discourse document has different attributes or properties of the associated entities.
The entities properties appearing in the domain of discourse material will not conform to the scenario description if one decides to add information in the document to the scenario description. It will also generate data redundancy if the database stores a large amount of information.
Useful Pieces of Information in the Domain of Discourse Document
The entity attributes that make up the hospital database are a significant example of useful information. The attribute defines the table properties of the database. With the definition of the attributes, one can distinguish the table fields. For instance, doctor relation has three essential attributes, which involves staff no, doctor name, and position.
Defining the associated data types of the table is another useful information that the discourse of document provides. The document describes the relational data types of the hospital database. It specifies the data types such as characters, integers, date, decimal, etc. For instance, the Ward entity involves two associated data types. The Ward No is of integer data type, the number of beds is of integer data type, while the Ward Name is of character data type. This critical approach allows relevant data to be stored in the database.
The document outlines the relationship of the associated tables. Thus, it defines the tables that have a many-many relationship and one-many relationship. For instance, each team member encompasses one or more doctors. With this approach, the relationship between the team and the staff entity is one-many. This fundamental property allows tables to be linked to each other to enhance multiplicity.
Specifying table constraints is another useful information that the document provides. The constraints domains guarantee table restriction when it is about to delete or update table records. For instance, a consultant is part of a team member that specifies entity restriction. It also offers insertion restraints when a user is about to input a new record.
The document specifies the unique key and non-key attributes of the relations. The non-key attributes do not functionally depend on the primary key of the table. With this relational assumption, the tables have primary keys, and that distinguishes them from the other tables. For instance, the Prescription No is the primary key attribute in the Prescription entity.
Table collation is another relevant information in the domain of discourse document. The relational collation provides the language of the table. Because of this, a person is aware of the used table language, including Latin, English, Swedish, etc.
The domain of discourse file holds default values of the relation. It allows one to distinguish if the associated tables support null values or non-null values. This method allows the hospital database to hold a particular type of values.
The document contains the data format of the hospital database. It defines the data composition, for instance, compact data, which enhances data backup, file transfer from the hospital database to other databases.
The Organization of Domain Discourse Document and Purpose of Occurrence Diagram
The domain of discourse document is structured into the entity type catalog and the relationship catalog. The entity type list outlines the relevant entity types or the tables. For instance, the document highlights the Nurse entity that comprises of two attributes, including Staff No and Nurse Name. However, the relationship catalog illustrates the link that exists between the tables. For instance, many patients can occupy a Ward, and this suggests a one-many relationship between the patient and the ward entity.
The occurrence diagrams illustrate the event sequence from the scenario descriptions. It determines the entities and relations involved in the scenario explanation. With this, one is able to develop relevant tables with their corresponding relationships needed for database design.
The Main Idea of OODBMS
The significant concept of the object-oriented database management system (OODBMS) is that it maintains the modeling and generation of data as objects. This approach entails handling classes of objects, inheriting data properties and methods of class, subclasses and their predefined objects (Connolly & Begg 2014). With this, the physical representation of data objects is noticeable only to the constructor of the object.
Differences between OODBMS and Relational Database Management Systems (RDMS)
The OODBMS creates data and represents information in the form of objects. With this approach, it maintains object classes, state properties, and inheritance of methods by objects and subclasses. In contrast, the RDBMS creates and represents information in the form of the relational model (Connolly & Begg 2014). It stores the data in the relational tables. The OODBMS supports class of objects, which involves the common properties of objects in that given class. Contrastingly, the RDBMS relies on the entity types, which defines a particular table.
Additionally, the OODBMS depends on the class hierarchy for determining objects inheritance while he RDBMS relies on the external keys for deciding the table relationship (Foster & Godbole 2013). The class instance of OODBMS may primarily involve one or more restrictive objects activity, which its methods define. Comparably, the RDBMS may have entities that are identified by the primary keys, while the system defines the object identifiers of OODBMs.
Advantages and Disadvantages of the OODBMS against the RDBMS
The OODBMS is capable of supporting various data types such as pictures, text, etc. This approach is possible since it maintains data as objects. Eliminating the data mismatch is another significant advantage of the OODBMS against the RDBMS (Kroenke & Auer 2014). It guarantees this by integrating the object-oriented programming with the essential data manipulation language. With this approach, the objects can have extents of data types to support complex data. The OODBMS also enhances productivity via inheritance and polymorphism of the defined objects. The objects can further expand this activity to create class behaviors exclusive to these objects.
Another key advantage is that it does not rely on the primary keys like the RDBMS for identifying objects. Instead, it relies on object identifiers that are not visible to the user. Because of this, a user can store an array of values in an object without system restriction. Furthermore, the OODBMS offers more data extensibility than the RDBMS to be created from the defined data types such as subclass to superclass inheritance. This behavior minimizes data redundancy within the system (Foster & Godbole 2013).
The notable drawback of the OODBMS is missing the universal data model. The database developers have not yet standardized the data model, and it lacks the theoretical base. Contrastingly, the use of relations in the RDBMS is universally accepted and it has a stronger theoretical foundation (Connolly & Begg 2014).
It also supports complex functionalities, including version handling, schema expansion, and data pointer management. Because of this, managing of data using the OODBMS is challenging for the new users. Comparably, managing data in the RDBMS is not complex since the data resides in multiple entities related to each other via associated values.
Types of Applications that would Better Fit the OODBS than Relational Model
The Computer Aided Software applications would be ideal for using an object database. These applications mostly require large complex data that object database supports (Foster & Godbole 2013). It also maintains sophisticated data relationships such as many-many object relationship, that database object models will create and support.
The multimedia programs are other imperative applications that database object models support. These systems require a database that can keep various types of data such as pictures, text, audio, and numbers (Foster & Godbole 2013). The OODBMS provides this capability of supporting a broad array of data and because of this, it would be suitable for multimedia applications. Notably, other critical applications, which the OODBMS model would support, include commerce applications and objects projects that would develop over time.
The Entity Types
The tourist agency scenario has approximately eight entity types. These associated entities include tourist, booking, tour group, tour package, package segment, staff, branch, and travel agency. The tourist entity has Tourist ID, Tourist Name, Telephone, Address, Sex, and Age as the essential attributes. The Tourist ID is the primary Key of this entity. The booking ID, Group ID, Booking Branch, Tourist ID, Date, and Price are the key attributes of the booking entity. The booking ID is the unique key while the Tourist ID and Group ID are the foreign keys of this table.
Additionally, the Travel Agency entity includes attributes such as Agency ID, Name, Tourist ID, Address, Telephone, Nationality, and Tourist ID as the primary table properties. The attribute Agency ID is the primary key for this relation. With this, the Travel Agency keeps the tourist information. This approach implies that the relationship, which exists between the Travel Agency and the tourist, is one-many. It means that a travel agency can store much information of the tourist.
The Tour Group entity includes attributes such as Group ID, Group Name, Start Date, Maximum Capacity, Group Status, Tourist ID, and Staff ID. With this information, the Group ID is the primary key of the table. Nevertheless, the attributes such as Tourist ID and Staff ID are the foreign keys of this table. The Tourist Package entity has Package ID, Name, Description, Group ID, Staff ID, and Segment ID as the notable attributes.
The Package ID is the primary key of this table while Group ID, Staff ID, and Segment ID are the Foreign Key. This property implies that these keys are the primary keys of other attributes (Gillenson 2012). Lastly, the Package Segment entity holds significant attributes such as Segment ID, Duration, Start Location, End Location, Segment Type, and price. With these properties, Segment ID is the primary key of this relation.
Assumptions and Associated Entity Relationships
The tour group involves bookings entity that the tourists have made. However, at times, the tour group might not constitute any reservation that the tourists have made. With this significant assumption, the relationship between the booking entity and the tour group table is a one-many relationship. It implies that a particular tour group can constitute more than one booking. Additionally, the staff member manages the tour group that belongs to a particular package. The assumption implies that the link that exists between the staff entity and tour group entity is a one-one relationship (Kroenke & Auer 2014). Because of this, the staff ID will be the foreign key in the tour group table and a primary key in the staff entity. Most importantly, the group status attribute of the tour group entity will have an extended sub-attribute since the group status can be either open, closed, or canceled.
Additional Constraints of the Entities
The staff entity has a key additional constraint that relates to the Tour Package relation in the database. The restriction is that the staff cannot take the role of a tour guide for more than one Tour Group at the same time. Owing to this, the constraints of the foreign key, which exist in the staff table, are on delete restrict and update restrict. Another restriction exists between the entity Booking and Tour Group. The number of reservations done by the Tour Group should not exceed the maximum capacity that the system sets. With this approach, the constraint that occurs in the booking entity is on delete restrict and on update restrict.
Limitation in the CDM
The main limitation is attempting to link a tourist entity using a package group entity and a branch entity since this would create data redundancy. Another limitation is that a tour package can encompass multiple tour groups and yet, the related keys do not exist between tour package and tour group entity (Kroenke & Auer 2014). Moreover, the application does not outline a significant link between the travel agency and the branch, which is an important section of the entity structure.
The conceptual data model will have four entity types with their respective attributes. The customer entity will involve essential attributes such as customer ID and Name. The attribute Customer ID is the primary key, while the name is the non-key attribute. It will also have the Order entity that will have Order ID, Customer ID, and Date as the notable attributes. The Order ID is the primary key, and the Customer ID is the foreign key in the Order entity. The item object will contain Item ID and Item Name. The item ID is the primary key. The sale item entity will have attributes, including order ID, Item ID, quantity, and unit price. The order ID is the foreign key of this table (Pratt & Adamski 2013).
Additional Constraints Section
The entity sale item has a referential constraint for enhancing data integrity. Both order ID and item ID attributes will support referential integrity constraint via update and delete. These attributes are set Null to guarantee referential actions (Pratt & Adamski 2013).
AB C, D, E, F, G
The primary key is AB while the non-primary key attributes are C, D, E, F, and G. They are very functionally dependent on the primary keys AB (Russell & Cohn 2012).
The attribute E is a new primary key.
No. Multiple repetitive candidate keys are not present (Russell & Cohn 2012).