click below
click below
Normal Size Small Size show me how
INFO MANAGEMENT L2
DATA MODEL
| Question | Answer |
|---|---|
| A relatively simple, usually graphical, abstraction of complex real-world data structures. It represents data, relationship between data, and constraints (rules) applied to the data. | Data Model |
| The process of creating a conceptual representation of data structures required by an organization. It's a method used to define and analyze data requirements needed to support the business processes. | Data Modeling |
| Data structured in a tree like format. A parent segment can have many children, but a child can have only one parent. | Hierarchical (1960s) |
| Extended the hierarchical model to allow a many-to-many relationship between records. | Network (1970s) |
| Data stored in independent tables. Relationships are established via shared keys. | Relational (1980s-Present) |
| Data and procedures (methods) are encapsulated into objects. | Object-Oriented (1990s) |
| Non-relational databases (e.g., Key-Value, Document, Graph) | NoSQL (2000s-Present) |
| Serves as a clear, visual guide for developers and system architects, ensuring a structured and high-quality database design. | Foundation/Blueprint: |
| enforces rules standards, and constraints, which makes the data accurate, consistent, and reliable (reducing redundancy and errors). | Data Quality |
| Provides a clear structure and analyzing data, leading to valuable insights for informed, data-driven decisions. | Business Value |
| Creates a common language (a single source of truth) between technical teams and business stakeholders, aligning requirements with design. | Communication |
| Logical organization and clarity simplify data management, speed up application development, and make systems easier to update and scale. | Efficiency/Cost |
| A person, place, thing, or event about which data will be collected and stored. Example: In a customer management system, "Customer," "Product," and "Order" are entities. Strictly no spaces (_), PascalCase, Plural Form | Entity/Table |
| These are the properties or characteristics that describe an entity. Example: For a "Customer" entity, attributes could include customer_last_name, customer_first_name, and customer_phone. Strictly nospaces (_), use camelCase, | Attribute/Columns |
| Describes an association between entities. Example: A relationship can exist between "Customer" and "Order" to show that a customer can place many orders. Common types include one-to-one (1:1), one-to-many (1:M), and many-to-many (M:M). | Relationship: |
| A restriction or rule placed on the data. Ensures data integrity. Example: A constraint could enforce that an Order must have a valid customer_id or that a price attribute must be a positive number. | Constraint |
| A high-level view of the entire data system. It defines the main entities and relationships without specifying too many technical details. | Conceptual Data Model: |
| A more detailed model that describes the data in more detail, including all the entities, attributes, and relationships. It's independent of any specific database system but lays the groundwork for it. | Logical Data Model: |
| The most detailed level. It specifies how the data will be physically stored in the database, including table types, column data types, and other physical storage considerations. | Physical Data Model: |
| re the logic and constraints that define how an organization's data is used, managed, and structured. They are precise descriptions of policies, procedures, or principles within a specific organization. | Business rules |
| To create an effective data model, the designer must identify all relevant business rules. This is typically done through structured analysis: | Discovering Business Rules |