ISM 301 Ch9: Data Management Layer Design PDF

Ch9: Data Managemen t Layer Design ISM 301 SDLC Idea Drawing Blueprint Construction Planning Analysis Development Implementation Data Management Layer Applications are of little use without the DATA. After defining classes and methods, it is crucial to determine how objects w...

Ch9: Data Managemen t Layer Design ISM 301 SDLC Idea Drawing Blueprint Construction Planning Analysis Development Implementation Data Management Layer Applications are of little use without the DATA. After defining classes and methods, it is crucial to determine how objects will persist beyond the application’s runtime. This involves: ◦Selecting the format of storage ◦Mapping the problem domain classes to object persistence format ◦Designing necessary data access and manipulation Selecting the format of storage Object Persistence Formats Object persistence refers to the ability of objects to outlive the application process that created them. This is essential for retaining data between sessions. Common methods for achieving persistence include: Files: Storing data in flat files, which can be sequential or random-access. Databases: Utilizing Database Management Systems (DBMS) to manage structured collections of data.  Files vs Database Mario’s Auto Shop- Two File Oriented Systems Danica’s Auto Shop Database System Danica’s SHOP OPERATIONS SYSTEM uses a database design, which avoids duplication. The data can be viewed as if it were one large table, regardless of where the data is stored physically. Mario’s shop uses two separate file-oriented systems, so certain data must be entered twice. This redundancy is inefficient and can produce data errors, especially in complex systems. Database Management System(DBMS) A database is a collection of groupings of information, each of which is related to each other in some way (e.g., through common fields). Logical groupings of information could include such categories as customer data, information about an order, product information, and so on. A database management system (DBMS) is software that creates and manipulates these databases. They enable users to add, update, manage, access, and analyze data. E.g., MS Access, MySQL, Oracle, DB2, MS SQL, NOSQL Advantages of DBMS Databases offer a more structured approach to data storage, enabling complex querying and relationships between data entities. o Scalability - System can be expanded/downsized o Economies of scale -Database design allows high-volume data processing yet efficient utilization of resources. o Improved Security- Only legitimate users can access the database o Enterprise-wide application- Different users have different levels of access. o Concurrent Access- Multiple users or systems need to access and modify the data simultaneously. Relational Database A relational database is based on collections of tables. Each table has a Primary key—a field or fields whose values are unique for every row of the table. The tables are related to one another by placing the primary key from one table into the related table as a Foreign key. Relational database management systems (RDBMS) support referential integrity, or the idea of ensuring that values linking the tables together through the primary and foreign keys are valid and correctly synchronized. Table s Types of Databases Relational Databases (RDBMS) Object-Relational Databases (ORDBMS) Object-Oriented Databases (OODBMS) NoSQL Data Stores Mapping the problem domain classes to object persistence format Mapping from problem domain to data Mapping means connecting the elements of the system’s design—like classes and their attributes (e.g., a Patient class with name and age attributes)—to the way data is stored in a database. It is like creating a “translation guide” that ensures that system’s objects (like Patient, Order) are accurately represented in the database, whether that database stores data in tables, objects, or other formats. Why is it important? Maintains relationship: maintaining the logical relationships Improve efficiency: Optimizes access and management of data Scalability and Maintainability: Makes future changes much easier Reusability and Flexibility: The problem domain classes remain independent of the format, thus allowing reuse and adaptation. Mapping to RDBMS Rule 1: Map Concrete Classes to RDBMS Table Concrete Tables Class E.g., Patient class maps to Patient table. R1 Rule 2: Map Attributes to Table R2 Columns. Attributes of the class become columns in the table. E.g., Patient attributes like insurance carriers become columns in Patient Table.  Mapping to RDBMS Rule 3: Implement Methods as Stored Procedures E.g., For a calculateLastVisit() method in Patient, a stored procedure in the database could compute last visit from appointment. Rule 4: Map single‐valued aggregation and association relationships to a column that can store the key of the related table, i.e., add a foreign key to the table. Do this for both sides of the relationship. In a one-to-one relationship, use an Object ID (like a foreign key) to link related tables. R3 Example: A specific symptom suffered by a patient, R4 The Suffer table could have a participantNumber column referencing the Patient table..  Mapping to RDBMS Rule 5: Map multivalued attributes and repeating groups to new tables R5 and create a one‐to‐many association from the original table to the new ones For attributes that can hold multiple values (like multiple insurance providers for a Patient), either store multiple values in one column or create a separate table. E.g., In the Patient table, InsuranceCarrier could be a column that stores multiple IDs. Alternatively, create a Patient-Insurance table linking Patient Table to Insurance Carrier Table. R6 Rule 6: Map multivalued aggregation and association relationships to a new associative table that relates the two original tables together. Copy the primary key from both original tables to the new associative table, i.e., add foreign keys to the table. E.g., create a new table, “suffer,” that represents the association between the patient and Symptoms problem domain classes.  Mapping to RDBMS Rule 7: Map Mixed Relationships by Adding Foreign Keys For relationships that mix one-to-one and many-to-many, add foreign keys to represent connections. R7 R8a Example: In a patient-to-appointment relationship, where a patient can have multiple appointments, a patient ID would be in the Appointment table. Rules for Inheritance: Rule 8a: Ensure subclass keys match superclass keys if both are stored. Example: If Participant is a superclass of Patient, use the same primary key for both tables (e.g., ParticipantNumber as patient id). Rule 8b: Flatten hierarchy by copying superclass attributes. Example: Copy all Participant attributes into Patient if Patient inherits from Person. Designing necessary data access and manipulation Data Access and Manipulation (DAM) classes Data Access and Manipulation (DAM) classes are a “middle layer” in the system. RDBMS Table Problem-Domain They connect the core classes that DAM CLASSS Class define the main business logic (problem domain classes) with the database (object persistence classes). DAM classes allow the application to interact with the database without directly connecting the core logic to the database, which keeps the design modular and flexible. DAMS Class Translator Role: DAM classes act as translators between the problem domain classes (like Patient or Appointment) and the database. They handle reading and writing data, allowing the application to save, retrieve, and update data without directly interacting with the database. One DAM Class Per Problem Domain Class: For each problem domain class, like Patient or Symptom, there is typically one DAM class (e.g., Patient-DAM, Symptom- DAM). This setup keeps things organized and makes sure that each DAM class has a clear, focused responsibility. Example of DAM Class Patient-DAM Class: The Patient-DAM class would handle tasks like: Write a Patient Table: It takes data from a Patient object and stores it in the Patient table. Writing a Patient: It fetches data from the Patient table and creates a Patient object from it. This way, if you ever need to switch to a different database, you would only have to update the Patient-DAM class, not the Patient class.  End of THANK YOU Chapter