📦Data Migrations (DM): Conceptualization (Part VII: Data Import Layer)

Data Migrations Series

The data requirements for the Data Migration (DM) and Data Quality (DQ) are driven by the processes implemented in the target system(s). Therefore, a good knowledge of these requirements can decrease the effort needed for these two subprojects considerably. The needed knowledge basis starts with the entities and their attributes, the dependencies existing between them and the various rules that apply, and ends with the parametrization requirements, respectively the architecture(s) that can be used to import the data.

The DM process starts with defining the entities in scope and their attributes, respectively identifying the corresponding entities and attributes from the legacy systems. The attributes not having a correspondent in the legacy system need to be provided by the business and integrated in the DM logic. In addition, it’s needed to consider also the attributes needed by the business and not available in the target system, some of them more likely available in the legacy systems. For such attributes is needed either to misuse an attribute from the target or to extend the target system.

For each entity is created a data mapping that basically documents the data transformations needed for migrating the data. In the process is needed to consider also attributes’ data types, the (standard) formatting, their domain of definition, as well the various rules that apply. Their implementation belongs into the DM layer from which the data are exported in a standard format as needed by the target system.

Exporting the data from the DM layer directly into the target system’s tables has in theory the lowest overhead even if the rejected records are difficult to track, the rejections resulting only from records’ ‘validation against database’s schema. For this approach to work, one must have a good knowledge of the database schema and of the business rules implemented into the target system.

To solve the issue with errors’ logging, systems have a further layer on top of the database model, which also allow running data validation against target system’s business rules. Modern import frameworks allow loading the data via a set of standard files with a predefined structure. The data can be thus imported manually or via load jobs into the system a log with the issues being generated in the process. Some frameworks allow even the manual editing of failed records, respectively to import the data. Unfortunately, calling the layer from the DM layer is not possible from a database, though this would bring seldom a benefit. Some third-party tools attempt to improve the import functionality by calling the target system’s import layer.

The import files must be generated from the DM layer in the required structure with the appropriate formatting. The challenge however resides in identifying all the attributes that should make scope of the load. It’s an iterative process which sometimes is backed by try-and-error heuristics. Unless target system’s validation rules are known beforehand, the rules need to be discovered in this process, which can prove time-consuming. The discoveries need to be integrated also in the DM and from here results the big number of changes that need to be performed.

Given the dependencies existing between entities the files need to be generated and loaded in a predefined order. These dependencies are reflected also in the data processing and the validation rules considered in the DM layer.

A quality checkpoint can be implemented between the export from the DM layer and import to enforce the four-eyes principle. It’s normally the last opportunity for trapping the eventual issues. A further quality check is performed after import by validating on whether the data were imported as expected.

Previous Post <<||>> Next Post

🧊Data Warehousing: ETL (Part III: The Extract Subprocess)

 

Data Warehousing Series

As part of the ETL process with applicability to Data Warehousing, Data Migrations, Data Integrations or similar scenarios the extraction subprocess is responsible for preparing and implementing the logic required to extract the data from the various source systems at the required level of detail. The extraction is done typically based on SQL queries as long one deals with relational databases or any OLEDB or ODBC-based data repositories including flat or MS Office files.

One can consider the preparation of the extraction logic as separate design subprocess of the targeted solution. Even if high-level design decisions are considered at the respective level, the low-level design needs to be considered at ETL package level. As part of the process are identified the source of the data in terms of system, tables and attributes to be imported, as well the joins, business and transformation rules that need to be applied on the data. This can involve reengineering the logic from the source system(s) as well data profiling, discovery or exploration activities.

A common practice is to copy the source tables 1:1 into the solution, eventually by considering only the needed attributes to minimize the necessary space, loading time and content’s complexity, even if this would add more effort into the design phase to identify only the needed attributes. If further attributes are identified at a later stage, the packages need to be modified accordingly. If the data volume or the number of unnecessary attributes is neglectable, copying the table 1:1 could prove to be the best strategy.

A second approach is to model within the extraction the (business) entity as designed within the source system. For example, the entity could be split over multiple tables from design or other purposes. Thus, the extraction query will attempt modeling the entity. This approach reduces to some degree the number of tables from the targeted solution, as well the number of ETL packages involved, while providing a clear depiction of the entities involved.

A third approach is to extract the data as needed by the target system, eventually as a mix between master and transaction data, fact which could easily lead to data redundancy with different timeliness and all the consequences resulting from this. This approach is usually met in solutions which require fast data availability in the detriment of design.

Unfortunately, there can be design constraints or choice considerations that could lead to a mix between these approaches. If the impact caused by the mix between the first two approaches is minimal, the third approach can cause more challenges, though it might be a small price to pay as long the considered data are disconnected from other data.

To reduce the redundancy of data, it’s recommended to consider as goal creating a unique source of facts, which can be obtained by minimizing as much as possible the overlaps between tables, respectively entities. Ideally there should be no overlaps. On the other sides the overlaps can be acceptable when the same data are available in more systems and the solution requires all the data to be available.

If the above approaches consider the vertical partitioning of the data, there can be also horizontal partitioning needs especially when a subset of the data is needed or when is needed to partition the data based on a set of values. In addition, one might be forced to include also transformation rules directly into the extraction logic, for example to handle conversion issues or minimize certain design overhead early in the process. In practice it makes sense to link such choices to business rules and document them accordingly.

Previous Post <<||>> Next Post

⛏️Data Management: Data Flow (Definitions)

"The sequence in which data transfer, use, and transformation are performed during the execution of a computer program."  (IEEE," IEEE Standard Glossary of Software Engineering Terminology", 1990)

"A component of a SQL Server Integration Services package that controls the flow of data within the package." (Marilyn Miller-White et al, "MCITP Administrator: Microsoft® SQL Server™ 2005 Optimization and Maintenance 70-444", 2007)

"Activities of a business process may exchange data during the execution of the process. The data flow graph of the process connects activities that exchange data and - in some notations - may also represent which input/output parameters of the activities are involved." (Cesare Pautasso, "Compiling Business Process Models into Executable Code", 2009)

"Data dependency and data movement between process steps to ensure that required data is available to a process step at execution time." (Christoph Bussler, "B2B and EAI with Business Process Management", 2009)

[logical data flow:] "A data flow diagram that describes the flow of information in an enterprise without regard to any mechanisms that might be required to support that flow." (David C Hay, "Data Model Patterns: A Metadata Map", 2010)

[physical data flow:] "A data flow diagram that identifies and represents data flows and processes in terms of the mechanisms currently used to carry them out." (David C Hay, "Data Model Patterns: A Metadata Map", 2010)

"The fact that data, in the form of a virtual entity class, can be sent from a party, position, external entity, or system process to a party, position, external entity, or system process." (David C Hay, "Data Model Patterns: A Metadata Map", 2010)

"An abstract representation of the sequence and possible changes of the state of data objects, where the state of an object is any of: creation, usage, or destruction [Beizer]." (International Qualifications Board for Business Analysis, "Standard glossary of terms used in Software Engineering", 2011)

"Data flow refers to the movement of data from one purpose to another; also the movement of data through a set of systems, or through a set of transformations within one system; it is a nontechnical description of how data is processed. See also Data Chain." (Laura Sebastian-Coleman, "Measuring Data Quality for Ongoing Improvement ", 2012)

"The movement of data through a group of connected elements that extract, transform, and load data." (Microsoft, "SQL Server 2012 Glossary", 2012)

"A path that carries packets of information of known composition; a roadway for data. Every data flow’s composition is recorded in the data dictionary." (James Robertson et al, "Complete Systems Analysis: The Workbook, the Textbook, the Answers", 2013)

"the path, in information systems or otherwise, through which data move during the active phase of a study." (Meredith Zozus, "The Data Book: Collection and Management of Research Data", 2017)

"The lifecycle movement and storage of data assets along business process networks, including creation and collection from external sources, movement within and between internal business units, and departure through disposal, archiving, or as products or other outputs." (Kevin J Sweeney, "Re-Imagining Data Governance", 2018)

"A graphical model that defines activities that extract data from flat files or relational tables, transform the data, and load it into a data warehouse, data mart, or staging table." (Sybase, "Open Server Server-Library/C Reference Manual", 2019)

"An abstract representation of the sequence and possible changes of the state of data objects, where the state of an object is any of: creation, usage, or destruction." (Software Quality Assurance)

📦Data Migrations (DM): An Introduction

Data Migrations Series

Introduction

Basically, Data Migration is the movement of data from one IS (Information System), the legacy system, to a new IS, the target system, supposed to replace entirely or partially the legacy system. In the best scenario there are no differences between the two IS or the differences are minimal, negligible. In the worst scenario, there are multiple legacy systems used as source, and even multiple target systems, with important differences between them, differences that can even be translated in incompatibilities at multiple levels. Such architectures can span geographies, departments, organizations or industries; can involve a multitude of vendors, generations of systems, network types, different regulations, etc. In many Data Migrations the overall picture can be really complex, though for the sake of simplicity it’s enough to focus on the simplest scenario in which there is a single source and a single target system, with some differences between them. Abstraction can be made also of the fact that many migrations are parts of bigger projects, for example ERP implementations or any other type of applications migrations.

Data Migration is quite a complex topic, for many appearing like a black box in which data come in and data come out. That’s valid for the typical user as well for the IT professionals who haven’t been involved in Data Migration projects. There are many books on topics that are tangent to Data Migration – Data Management, Data Quality, Data Integration or Data Warehousing. Excepting some presentations available on the Web, a few methodologies exposed by important companies, one or two books, and a few blogs, there isn’t much material available on Data Migration. The “trend” is also a reflection of the low importance given to Data Migration as subject, even if many professionals working in the field warn about the considerable impact a Data Migration can have on a project in particular, and on business in general.

Approaching a topic like Data Migration can be, upon case, a complex task, however with a little intuition and some guidance its complexity falls apart. Often, when exploring such a topic, of help can be the 5W1H technique or its extended forms. The technique resumes to searching for answers to the “what”, “where”, “why”, “how”, “when”, “who” and “with what” questions. In case of Data Migration the questions are formulated as: what (data) to migrate, where to migrate, why to migrate, how to migrate, when to migrate, who migrates and with what to migrate?

Why to migrate?

A Data Migration occurs as follow up of a need – an old system exists in place and can’t cope anymore with business’ growth, a company made an acquisition and the systems need to be consolidated, or the organization decided to change its infrastructure, the processes, the business model in order address nowadays business requirements like flexibility, availability, manageability, automation, cost cuts, etc. In other words a Data Migration occurs as a need for change, and it can be itself a change in what concerns technical infrastructure, process, procedures, data flow, ways of doing business. A migration has quite an impact on the business, so here is an entitled question: does it really makes sense to migrate? Why not start from 0 with the new system?!

The migration can be a 0 point for an organization, though unless a company is starting anew, there are some data laying there in the old system(s) that need to be further available - for example open Purchase Orders that need to be fulfilled, Invoices that need to be paid, a catalog with all the Products and the available stock, information about Customers, what they bought, what they browsed or what they want to buy for Christmas, etc. At least some of the data need to be made available in one form and another also within the new architecture, if not the new system.

The availability of old data can be solved by keeping the old system(s) in place, functional, even if the system won’t be fed with new data, or maybe it will. Keeping a system alive involves additional costs for maintaining the infrastructure – software and hardware licenses, consultants, administrators and other people responsible for the optimal work of such a system. This can become with time quite an unnecessary burden. It can be an acceptable choice for some organizations, but unlikely as best/good practice. And even if the system is kept, more likely there will be data that need to be available also in the new system. Can be discussed also about integration of the two systems, but again, does it make sense? The bottom line is that in multiple scenarios a Data Migration can prove to be the optimal solution for an organization.

What data to migrate?

Even if it looks like a silly question, it can be one of most complex questions to answer. In theory is needed to migrate all the data, but are really needed all the data? Typically in a database can be found historical data not used anymore by the business, obsolete data marked or not for deletion, garbage data entered by mistake or remained after incomplete deletions, all these having low or no value for the business. Hopefully there are also “good data”, quintessential for the business. Somebody would say “what a hack, why do we need to philosophize so much, let’s migrate all the data!”. The decision can be understandable, though what if the percentage of “good data” is quite small in comparison with the total volume of data which can measure a few terabytes?! Sure, nowadays data centers can handle without problems terabytes of data, though there are some factors to be considered – it can be quite a challenge to migrate so many data, the volume of data affects also the performance of databases in particular, and IS in general, and a more natural reason – why store something that has minimal value for you?!

It makes sense to migrate only the data that have value for an organization, but what data are needed then? Normally this starts by understanding what entities the business deals with and which are the attributes that characterizes them. Many of the entities can be met in organization’s daily activity, and maybe are already defined in organization’s glossary or Data Dictionary, so a review of the available inventory might do. If not, more effort needs to be spent for this purpose; activities specific to Data Discovery, Data Categorization, Data Definition or Data Profiling tasks can help after case to fill the understanding gaps. Except categorization the others are not all necessary, same as the analysis can be deep enough to serve the purpose.

A first categorization was made above when data were considered as valuable, not valuable or in between. A second categorization can be made based on data’s usage: obsolete (not used anymore or marked for deletion), new (not used and recently entered), historical (data used in the past) and actual (data in use). A third categorization can be made on the status of the entities they represent, status that can be associated to the phase of the process the entity represent (e.g. active, inactive, open, invoices, closed, blocked, etc.). There can be considered other meaningful categorizations as long they prove to be important in identifying the useful data.

An important categorization in migrations, in particular, and Data Management, in general, is to split data in master data, transaction data and setup data. Master data are data are data that change only seldom and have a long life (until become obsolete), are referenced through all the system, and are vital to an organization through their meaning (e.g. Customers, Suppliers, Products, Assets, Employees, Accounts, etc.). Transaction data in exchange are data that change often and have a relatively short life, typically are referenced by other transactions and can be associated with documents or movements through the system (e.g. Purchase Orders, Sales Orders, Invoices, Receipts, Assets Movements, etc.). Setup data are data used to configure a system (e.g. Transaction Types, Document Types, Roles, Permissions, etc.). This categorization deserves the full attention, because each of the three elements needs a different handling approach in migration or Data Management.

Based on the identified categories can be considered some rough migration rules in deciding what data (actually records) to migrate, for example: - master data, unless they become obsolete, and open transactions are often considered to be migrated entirely; - historical transaction data spanning a few years back can be migrated in case they are needed in the process; - master data referenced by transaction data migrated need to be migrated too - setup data are entered manually - historical data are archived. There can be also exceptions from the rules, so such possible scenarios need to be considered too.

Each entity is defined by multiple attributes (also called properties, dimensions). They need to go through a similar “categorization” process. In deciding what attributes to migrate is important to consider especially their role in defining the entity. Some of them define uniquely an entity (e.g. Customer Number, Product Number, Serial Number), physical characteristics of the entity (e.g. color, weight, height), categorize the entity (e.g. Category, Type) or its status (e.g. Active, Blocked, Invoiced), imply various events (e.g. Creation Date, Delivery Date, Invoice Date), and so on. It looks like another type of categorization, and it is, though it’s more difficult to create some rough rules based on it, because in the end the business dictates which Attributes are needed. In fact, most of the Attributes used (with distinct not null values) in the legacy system are more likely needed also in the new system, unless the process changed considerably, or the business is supposed to change also its model.

Where to migrate the data?

When the Data Migration subject is brought on the table, a decision was already made about the target system. So the “where” question is partially answered, however it addresses only the peak of the iceberg. It shows that an iceberg lies there, in front of us, though under the deep of the waters there is something more, lot of questions and issues that need to be addressed. Like the source, the target needs to be further detailed in entities and their attributes; the targeted processes and procedures need to be considered together with the constraints imposed by the new system. It’s actually needed to identify the data requirements for the new systems and corroborate them with the requirements of the old system. Mapping the entities and attributes available in the two systems, process known as Data Mapping, can offer a good overview of what lays ahead, what similarities and gaps exist. There will be attributes that are available in the legacy but not in the target system, and therefore the target system needs to be extended or the data associated with the respective attributes can be left out. From the opposed perspective, there can be mandatory attributes in the target system which are not available in the organization, and therefore the associated data must be collected and/or made available for the migration. There can be cases when the data are not available in the legacy system but distributed in various other external or internal sources, so there can be an option to migrate or integrate the respective data, extend the processes to accommodate such scenarios, etc.

Only when the mapping of data is ready and the various related questions addressed, the “where” question is fully answered. Given the continuous changes done to the target system that may still happen a few days before Go Live, Data Mapping can remain a hot topic until then.

With what to migrate?

This question addresses the mix of tools used to migrate the data, and by extension the whole architecture developed for this purpose. As many experts point out, there is no general solution for such an approach because each migration is challenged by different requirements and architectures. ETL (Extract, Transform, Load) and Data Integration tools were mainly designed for this kind of purposes – moving data between data sources – therefore more likely the whole Data Migration architecture will be built around such a tool. In addition is needed to be addressed topics like assessment and reporting of Data Quality, Data Cleaning, Data Enrichment, Data Backup or Data Security. They will technically ensure that the data are migrated within intended level of quality and security.

For each of these topics are available one or more tools on the market. The challenge is to find the right mixture for the overall architecture, to make them work together in an efficient and effective manner. One of the problems such tools have is that they look to the Data Migration or similar problems from their own perspective, making them hard to integrate with other tools. Given the increasing need for Data Migration, more likely exist there tools that cover most of its requirements, each with its own advantages and disadvantages. Starting with a new tool can prove to be quite challenge in itself. Many recommend following a methodology and using tools that already proved their capabilities in other projects. That’s a good approach, though need to be considered also costs, available resources, effort to build the infrastructure, the learning curve, etc. For some migrations MS Excel or Access will do, for others a more complex framework is needed. Keep in mind that there is no perfect architecture, just the architecture that will drive you to achieve your targets.

How to migrate the data?

“How” refers mainly to the migration approach, steps, methodologies, processes and procedures used to migrate the data. Secondly, and not less important, it refers to how the mix of tools is used for migration – in other words the implementation. Despite the huge variety of tools and means of achieving the target, there can be depicted some generalities for each of these topics.

Migration approach refers to the overall strategy considered for a migration – typically on whether the data are migrated all together, the new system becoming functional and replacing the legacy system (the big-bang migration), or the data are migrated in phases, the legacy and target systems functioning in parallel for a certain amount of time (the phased-out migration). Can be met other variations of migration approaches, under various denominations. It’s important to know the advantages and disadvantages of both or all approaches, especially in what concerns their application in your organization.

“Steps” is just a misnomer for the actual Project Plan in which are considered the different phases and activities of such a project. In a general Data Migration project, can be discussed about Data Discovery, Data Definition, Data Collection, Data Consolidation, Data Mapping, Data Conversion, Data Transformation, Data Quality Assessment, Data Cleaning, Data Storage, etc. Some of these steps can be considered as standalone processes, sometimes being already part of the processes’ landscape existing in an organization. Other steps are just simple activities. Both types of steps share some important characteristics – they can be highly iterative and complex, are owned by the business, the IT functioning as facilitator, each of them depends on the input from other steps, and require continuous feedback, etc.

A Data Migration is (should be) managed as any other IT project, and therefore can be discussed about project-specific methodologies like PMBOK, Prince2 or PRISM. Many of the before mentioned steps come with their luggage of methodologies too. In addition, considering that IT functions as a service, could be considered service-specific methodologies like ITIL, ISO/IEC, Six Sigma, etc.

The actual implementation of all these depends entirely on the project’s scope, the knowledge of all those involved, the constraints met and the resources available for such a project. Many of the IT-specific problems and situations are specific across all IT projects.

Who will migrate the data?

There is no Data Migration project that can be done without the business, the de facto owner of such a project and its output. There is lot of input needed from the business, its continuous involvement through the various stages is necessary for the whole duration. Unless the Data Migration resumes to a rudimentary tool like Excel and can be handled without too much expertise, a Data Migration needs technical resources that can elicit the requirements, translate them in technical requirements, built the infrastructure and maybe migrate the data. It entirely depends on the overall architecture and methodology what people are involved. In the best case scenario the migration will resume to one person pushing a button and the data flow as magic from source to the target system. In reality, multiple people will have to take care of migration, pushing some magic buttons in a chain of parallel and even redundant steps, monitoring and validating the process. Data owners, data stewards, data custodians, data architects, database administrators, migration and quality assurance specialists, developers, consultants and many other people can be involved, each of them playing their role.

When to migrate the data?

Intuitively, data are or should be migrated when the target system is ready to receive the new data, thus when the development was finished, the system tested, and all the preparation for Data Migration were made. The statement is valid for any type of migration. How such a date or dates are calculated when a project starts is in itself kind of science or just a matter of needs. There are projects in which the dates for each milestone or phase are calculated back from a desired Go Live date, or projects in which the Go Live is calculated incrementally based on the steps to be performed. For dates’ calculation can be used also benchmarking from the field. The bottom line is that the data must be migrated on time for the Go Live and with a minimum disruption for the business.

Conclusion

Whether standalone or as subproject of another project, a Data Migration can be or become quite a complex thematic that, through its outcomes, affects the business considerably. In the above paragraphs were considered some of the important aspects of such a project, the focus being more on figuring out what a migration implies rather than a detailed exploration. It’s also a mental exercise and an invitation into the thematic.

Previous Post <<||>> Next Post

🛢DBMS: One-to-One Relationship (Definitions)

"A single instance of one entity is associated with a single instance of another entity." (Owen Williams, "MCSE TestPrep: SQL Server 6.5 Design and Implementation", 1998)

"A relationship between two tables in which a single row in the first table can be related only to one row in the second table, and a row in the second table can be related to only one row in the first table. This type of relationship is unusual." (Microsoft Corporation, "SQL Server 7.0 System Administration Training Kit", 1999)

"A relationship type between tables where one row in a given table is related to only one or zero rows in a second table. This relationship type is often used for subtyping. For example, an EMPLOYEE table may hold the information common to all employees, while the FULLTIME, PARTTIME, and CONTRACTOR tables hold information unique to full-time employees, part-time employees, and contractors, respectively. These entities would be considered subtypes of an EMPLOYEE and maintain a one-to-one relationship with the EMPLOYEE table." (Bob Bryla, "Oracle Database Foundations", 2004)

"Occurs when one row or thing of an entity is associated with only one row or thing of another. One-to-one relationships are uncommon in the real world." (Thomas Moore, "EXAM CRAM™ 2: Designing and Implementing Databases with SQL Server 2000 Enterprise Edition", 2005)

"The relationship between two tables dictated by having one record in each table, and not more than one record in either table, related back to the other table." (Gavin Powell, "Beginning Database Design", 2006)

"A relationship between two tables in which a single row in the first table can be related to only one row in the second table, and a row in the second table can be related to only one row in the first table." (S. Sumathi & S. Esakkirajan, "Fundamentals of Relational Database Management Systems", 2007)

"Used in a relational database to denote that a single row in the parent table can be related to only one row in the related child table and that a row in the child table can be related to only a single row in the referenced parent table." (Victor Isakov et al, "MCITP Administrator: Microsoft SQL Server 2005 Optimization and Maintenance (70-444) Study Guide", 2007)

"Occurs when one record in a table corresponds to exactly one record in another table." (Rod Stephens, "Beginning Database Design Solutions", 2008)

"One of three types of relationships (associations among two or more entities) that are used by data models. In a 1:1 relationship, one entity instance is associated with only one instance of the related entity." (Carlos Coronel et al, "Database Systems: Design, Implementation, and Management" 9th Ed., 2011)

"A link between two entities in which the cardinality of both sides of the relationship is one." (Craig S Mullins, "Database Administration", 2012)

"A relationship between two entities in a database such that each instance of an entity is related to no more than one instance of the other entity." (Jan L Harrington, "Relational Database Design and Implementation" 3rd Ed., 2009)

🛢DBMS: Entity Relationship Diagram [ERD] (Definitions)

"A graphical method of showing the entities, relationships, and attributes in a data model." (Owen Williams, "MCSE TestPrep: SQL Server 6.5 Design and Implementation", 1998)

"Drawings of boxes and lines to communicate the relationship between tables. Both third normal form (3NF) and dimensional models can be represented as ER diagrams because both consist of joined relational tables. The key difference between the models is the degree of dimension normalization. A dimensional model is a second normal form (2NF) model." (Ralph Kimball & Margy Ross, "The Data Warehouse Toolkit" 2nd Ed., 2002)

"The ERD is a proven and reliable data-modeling approach with straightforward rules of construction. The normalization rules yield a stable, consistent data model that upholds the policies and rules of engagement established by the enterprise. The resulting database schema is the most efficient in terms of storage and data loading as well." (Claudia Imhoff et al, "Mastering Data Warehouse Design", 2003)

"A diagram that represents the structural contents (the fields) in tables for an entire schema, in a database. Additionally included are schematic representations of relationships between entities, represented by various types of relationships, plus primary and foreign keys." (Gavin Powell, "Beginning Database Design", 2006)

"A diagram (or graph) of entities and their relationships, and possibly the attributes of those entities." (Toby J Teorey, ", Database Modeling and Design" 4th Ed., 2010)

"A diagram that depicts an entity relationship model’s entities, attributes, and relations." (Carlos Coronel et al, "Database Systems: Design, Implementation, and Management" 9th Ed, 2011)

"The graphical diagram for an Entity Relationship data model. The underlying data model generally includes more semantics than is or can be represented in the view shown on the diagram, e.g., some business rules." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

 "An E/R diagram graphically depicts the entities and relationships of a data model." (Craig S Mullins, "Database Administration: The Complete Guide to DBA Practices and Procedures" 2nd Ed, 2012)

🛢DBMS: Entity-Relationship Model [ERM] (Definitions)

"A common way to organize, think about, or discuss the elements of the 'real world' that a database design will represent, by dividing them into entities and relationships." (Bill Pribyl & Steven Feuerstein, "Learning Oracle PL/SQL", 2001)

"A type of conceptual data model that represents structured data in terms of entities and relationships. An entity-relationship diagram can be used to represent information objects and their relationships visually. Because the constructs used in the entity-relationship model can easily be transformed into relational tables, this type of model is often used in database design." (J P Getty Trust, "Introduction to Metadata" 2nd Ed., 2008)

"A data model that is used to represent data in its purest form and to define relationships between different entities." (Laura Reeves, "A Manager's Guide to Data Warehousing", 2009)

"A technique for representing entity relationships that is independent of any specific data model and any specific software." (Jan L Harrington, "Relational Database Design and Implementation" 3rd Ed., 2009)

"A conceptual data model involving entities, relationships among entities, and attributes of those entities." (Toby J Teorey, ", Database Modeling and Design" 4th Ed., 2010)

"A data model developed by P. Chen in 1975. It describes relationships (1:1, 1:M, and M:N) among entities at the conceptual level with the help of ER diagrams." (Carlos Coronel et al, "Database Systems: Design, Implementation, and Management" 9th Ed., 2011)

"An abstract and conceptual representation of data. Entity-relationship model consists of a set of entities, characterized by attributes and linked by relationships." (International Qualifications Board for Business Analysis, "Standard glossary of terms used in Software Engineering", 2011)

"1.Generally, a record-based data modeling scheme that focuses on entities and relationships in the presentation of data model diagrams, thus suppressing the display of attributes. A true ER model allows multi-valued data items and repeating groups of items (nested relations, thus violating first normal form), retains M:N relationships, attributed relationships, subtypes/supertypes, ternary and higher-order relationships, none of which can be represented directly in a relational data model. A true ER model generally excludes (defers) the representation of entity identifiers and foreign keys. Originally proposed and named by Peter Chen (1976). 2.In relational modeling, the most popular style of data model, defining entities and the business relationships between the entities. Some more detailed models include also some of the attributes of these entities, usually those involved in the relationships as keys." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"A data management approach that graphically represents relationships between data. This allows developers to create new relationships between data sources without complex programming." (Marcia Kaufman et al, "Big Data For Dummies", 2013)

"A logical view of data within a system, representing the entities in the system as well as relationships among the entities, attributes of the entities, and attributes of the relationships." (IEEE 610.5-1990)

🛢DBMS: Row (Definitions)

"A set of related columns that describes a specific entity. Also called record." (Karen Paulsell et al, "Sybase SQL Server: Performance and Tuning Guide", 1996)

"A data structure that is a collection of elements (columns), each with its own name and type. A row can be accessed as a collective unit of elements, or the elements can be accessed individually. A row is equivalent to a record." (Microsoft Corporation, "SQL Server 7.0 System Administration Training Kit", 1999)

"In a relational database table, a primary key value plus the associated values of each non-key column. The number of rows usually varies over time." (Bill Pribyl & Steven Feuerstein, "Learning Oracle PL/SQL", 2001)

"A record in a relational table." (Ralph Kimball & Margy Ross, "The Data Warehouse Toolkit 2nd Ed ", 2002)

"The collection of elements that form a horizontal line in the table. Each row in the table represents a single occurrence of the object modeled by the table and stores the values for all the attributes of that object." (Anthony Sequeira & Brian Alderman, "The SQL Server 2000 Book", 2003)

"A group of one or more data elements in a database table that describes a person, place, or thing." (Bob Bryla, "Oracle Database Foundations", 2004)

"A single instance in a table. This is also called a record." (Sharon Allen & Evan Terry, "Beginning Relational Data Modeling" 2nd Ed., 2005)

"A group of related column values in a table. The corresponding formal database term is tuple." (Rod Stephens, "Beginning Database Design Solutions", 2008)

"An individual entry from a given table. For example, a table may contain details about thousands of customers; a specific customer’s data will be found in one row. See also record." (Robert D Schneider & Darril Gibson, "Microsoft SQL Server 2008 All-in-One Desk Reference For Dummies", 2008)

"A horizontal line in the table that contains all attributes of a single object modeled in the table." (Jim Joseph, "Microsoft SQL Server 2008 Reporting Services Unleashed", 2009)

"In relational theory, a set of values for a specified set of attributes." (David C Hay, "Data Model Patterns: A Metadata Map", 2010)

"A group of data items treated as a unit by an application; a record; a tuple in relational database terminology." (Toby J Teorey, ", Database Modeling and Design" 4th Ed., 2010)

"A set of column values describing one logical instance in a relational database table. Technically called a tuple in relational calculus. Equivalent to a record in a flat file." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"A set of column values describing one logical instance in a table." (Craig S Mullins, "Database Administration", 2012)

"The horizontal component of a table, consisting of a sequence of values, one for each column of the table." (Sybase, "Open Server Server-Library/C Reference Manual", 2019)

🛢DBMS: One-to-Many Relationship (Definitions)

"An instance of an entity is associated with zero or several instances of another entity." (Owen Williams, "MCSE TestPrep: SQL Server 6.5 Design and Implementation", 1998)

"A relationship between two tables in which a single row in the first table can be related to one or more rows in the second table, but a row in the second table can be related only to one row in the first table. A typical one-to-many relationship is between the publishers table and the titles table in the pubs sample database, in which each publisher can be related to several titles, but each title can be related to only one publisher." (Microsoft Corporation, "SQL Server 7.0 System Administration Training Kit", 1999)

"A logical data relationship in which the value of one data element can exist in combination with many values of another data element, but not vice versa." (Ralph Kimball & Margy Ross, "The Data Warehouse Toolkit" 2nd Ed., 2002)

"A relationship type between tables where one row in a given table is related to many other rows in a child table. The reverse condition, however, is not true. A given row in a child table is related to only one row in the parent table." (Bob Bryla, "Oracle Database Foundations", 2004)

"These relationships exist when a single instance of an entity (the parent entity) relates to many instances of another entity (the child entity). One-to-many relationships are the most common relationships in the real world." (Thomas Moore, "EXAM CRAM™ 2: Designing and Implementing Databases with SQL Server 2000 Enterprise Edition", 2005)

"The relationship between two tables dictated by having one record in one table, and many related records in another table." (Gavin Powell, "Beginning Database Design", 2006)

"The use of one key value from a dimension table in many rows of a fact table." (Reed Jacobsen & Stacia Misner, "Microsoft SQL Server 2005 Analysis Services Step by Step", 2006)

"A relationship between two tables in which a single row in the first table can be related to one or more rows in the second table, but a row in the second table can be related only to one row in the first table." (S. Sumathi & S. Esakkirajan, "Fundamentals of Relational Database Management Systems", 2007)

"Used in a relational database to denote that a single row in the parent table can be related to one or more rows in the related child table but that a row in the child table can be related to only a single row in the referenced parent table." (Marilyn Miller-White et al, "MCITP Administrator: Microsoft SQL Server 2005 Optimization and Maintenance 70-444", 2007)

"A relationship where one object of one type may correspond to many objects of another type. For example, one INSTRUCTOR may teach many COURSEs but each COURSE has only one INSTRUCTOR." (Rod Stephens, "Beginning Database Design Solutions", 2008)

"One of three types of relationships (associations among two or more entities) that are used by data models. In a 1:M relationship, one entity instance is associated with many instances of the related entity." (Carlos Coronel et al, "Database Systems: Design, Implementation, and Management" 9th Ed., 2011)

"A link between two entities in which the cardinality of one side of the relationship is one and the other is multiple." (Craig S Mullins, "Database Administration", 2012)

"A relationship in which the connected field is unique in one table and not unique in the other table." (Faithe Wempen, "Computing Fundamentals: Introduction to Computers", 2015)

"A relationship between two entities in a database such that one instance of an entity can be related to many instances of a second entity and the second entity can be related to only one instance of the first." (Jan L Harrington, "Relational Database Design and Implementation" 3rd Ed., 2009)

🛢DBMS: Conceptual Data Model (Definitions)

"Represents the overall logical structure of a database, which is independent of any software or data storage structure. A Conceptual model often contains data objects not yet implemented in the physical databases. It gives a formal representation of the data needed to run an enterprise or a business activity." (Sharon Allen & Evan Terry, "Beginning Relational Data Modeling" 2nd Ed., 2005)

"An organization of data that describes the relationships among the primitive data elements. For example, in the ER model, it is a diagram of the entities, their relationships, and their attributes." (Sam Lightstone et al, "Physical Database Design: The Database Professional’s Guide to Exploiting Indexes, Views, Storage, and More", 2007)

"An abstract model or representation of data for a particular domain, business enterprise, field of study, etc., independent of any specific software or information system. Usually expressed in terms of entities and relationships." (J P Getty Trust, "Introduction to Metadata" 2nd Ed., 2008)

"An organization of data that describes the relationships among the primitive data elements. For example, in the ER model, it is a diagram of the entities, their relationships, and their attributes." (Toby J Teorey, ", Database Modeling and Design" 4th Ed, 2010)

"In the ANSI four-schema architecture, this is a description of a portion of an enterprise in terms of the fundamental things of significant interest to it. They are fundamental in that most things seen by business owners are examples of these. The model is constructed in a rigorous manner, being fully normalized, eschewing many-to-many relationships and is expressed in terms of binary relationships only." (David C Hay, "Data Model Patterns: A Metadata Map", 2010)

"A data model that is presented at a high level of abstraction, hiding the underlying details, and making it easier for people to comprehend. A conceptual model should reflect the phenomena in the users' world being modeled as directly as possible, as close to the way the users think. For example, many-to-many relationships are common in conceptual models." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"A high-level data model identifying major entities and relationships, not fully attributed and therefore not necessarily normalized." (Craig S Mullins, "Database Administration: The Complete Guide to DBA Practices and Procedures" 2nd Ed., 2012)

"A high-level data modeling that specifies an abstract map of concepts and their relationships. SQL’s inherent hierarchical data modeling does this easily and naturally." (Michael M David & Lee Fesperman, "Advanced SQL Dynamic Data Modeling and Hierarchical Processing", 2013)

"A detailed model that captures the overall structure of organizational data that is independent of any database management system or other implementation considerations." (Jeffrey A. Hoffer et al, "Modern Systems Analysis and Design" 7th Ed., 2014)

"The output of the conceptual design process. The conceptual model provides a global view of an entire database. Describes the main data objects, avoiding details." (Carlos Coronel & Steven Morris, "Database Systems: Design, Implementation, & Management"  Ed. 11, 2014)

"A model of a database expressed at platform independent level; describes entities from a considered domain, properties of these entities, and the relationships between entities." (Iwona Dubielewicz et al, "Quality-Driven Database System Development within MDA Approach", 2015)

"The most abstract form of data model. It includes the important entities and the relationships among them and contains only major attributes." (Besma Khalfi et al, "Enhanced F-Perceptory Approach for Dealing with Geographic Data Imprecision from the Conceptual Modeling to the Fuzzy Geographical Database Building", 2017)

🛢DBMS: Entity Integrity (Definitions)

"Within a table, each row describes an entity that is a member of the set kept in the table. Entity integrity ensures that each row in the table is uniquely identifiable." (Owen Williams, "MCSE TestPrep: SQL Server 6.5 Design and Implementation", 1998)

"Integrity that defines a row as a unique entity for a particular table and ensures that the column cannot contain duplicate values. It usually enforces the primary key of a table (through indexes, UNIQUE constraints, or PRIMARY KEY constraints)." (Microsoft Corporation, "SQL Server 7.0 System Administration Training Kit", 1999)

"Entity integrity refers to a state in which all the rows in a database have a non-null primary key value, all tables have primary keys, and no table has any duplicate primary key values. Entity integrity ensures there are no duplicate entries for anything represented in the database." (Anthony Sequeira & Brian Alderman, "The SQL Server 2000 Book", 2003)

"A relational database integrity mechanism that ensures that duplicate rows do not exist in a table. Requiring that all rows in a table have a unique identifier." (Victor Isakov et al, "MCITP Administrator: Microsoft SQL Server 2005 Optimization and Maintenance (70-444) Study Guide", 2007)

"Integrity that defines a row as a unique entity for a particular table and ensures that the column cannot contain duplicate values." (S. Sumathi & S. Esakkirajan, "Fundamentals of Relational Database Management Systems", 2007)

"Requires that all tables have a primary key. The values in the primary key fields must be non-null and no two records can have the same primary key values." (Rod Stephens, "Beginning Database Design Solutions", 2008)

"A constraint on a relation that states that no part of the primary key can be null." (Jan L Harrington, "Relational Database Design and Implementation' 3rd Ed., 2009)

"The property of a relational table that guarantees that each entity has a unique value in a primary key and that there are no null values in the primary key." (Carlos Coronel et al, "Database Systems: Design, Implementation, and Management" 9th Ed., 2011)

"A state in which every row of every table can be uniquely identified." (Microsoft, "SQL Server 2012 Glossary", 2012)

"The most basic level of data integrity provided by relational databases stating that each occurrence of an entity must be uniquely identifiable." (Craig S Mullins, "Database Administration", 2012)

🛢DBMS: Relationship (Definitions)

"A logical linkage between two entities that describes how the entities are associated with each other." (Owen Williams, "MCSE TestPrep: SQL Server 6.5 Design and Implementation", 1998)

"A link between tables that references the primary key in one table to a foreign key in another table. The relationship line is represented in a database diagram by a solid line if referential integrity between the tables is enforced, or a dashed line if referential integrity is not enforced for INSERT and UPDATE transactions. The endpoints of a relationship line show a primary key symbol to denote a primary-key-to-foreign-key relationship or an infinity symbol to denote the foreign key side of a one-to-many relationship." (Microsoft Corporation, "SQL Server 7.0 System Administration Training Kit", 1999)

"In database design, a property that exists between two (or sometimes more) entities. The property may represent a state, a behavior, an action, or some other logical combination and usually has a verb phrase or prepositional phrase as its name. In some modeling techniques, each relationship has two directions of interpretation; for example, in a library application, considering the book and book copy entities, a book may be owned as one or more book copies, and a book copy must be of exactly one book." (Bill Pribyl & Steven Feuerstein, "Learning Oracle PL/SQL", 2001)

"A link between tables that references the primary key in one table to a foreign key in another table. In English Query, a relationship is an association between entities that describes what those entities have to do with one another." (Anthony Sequeira & Brian Alderman, "The SQL Server 2000 Book", 2003)

"A relationship documents the business rule associating two entities. The relationship is used to describe how the two entities are naturally linked to each other." (Claudia Imhoff et al, "Mastering Data Warehouse Design", 2003)

"A connection between two entities that signifies the presence of a business rule." (Margaret Y Chu, "Blissful Data ", 2004)

"A connection between entities ties a parent entity to a child entity through the Primary Key in one entity to a Foreign Key in another." (Thomas Moore, "EXAM CRAM™ 2: Designing and Implementing Databases with SQL Server 2000 Enterprise Edition", 2005)

"A logical link between two entities that represents a business rule or constraint." (Sharon Allen & Evan Terry, "Beginning Relational Data Modeling" 2nd Ed., 2005)

"A social association or connection between two or more people." (Victor Isakov et al, "MCITP Administrator: Microsoft SQL Server 2005 Optimization and Maintenance (70-444) Study Guide", 2007)

"An association between two tables. For example, if an order contains several order items, there is a one-to-many relationship between Orders and OrderItems tables. Don't confuse this term with "relation."" (Rod Stephens, "Beginning Database Design Solutions", 2008)

"A link between tables that references the primary key in one table to a foreign key in another table." (Jim Joseph, "Microsoft SQL Server 2008 Reporting Services Unleashed", 2009)

"A real-world association among one or more entities. For example, “purchased” could be a relationship between customer and product." (Toby J Teorey, ", Database Modeling and Design" 4th Ed., 2010)

"The complete association among specific entity classes consisting of two or more relationship roles." (David C Hay, "Data Model Patterns: A Metadata Map", 2010)

"An association between entities." (Carlos Coronel et al, "Database Systems: Design, Implementation, and Management" 9th Ed., 2011)

"Defines how different entities are associated with each other. A relationship is defined by the keys: the primary key in the parent entity and the foreign key in the dependent entity." (Craig S Mullins, "Database Administration", 2012)

"The association of two or more entities; through this association, it expresses the business policy of the data model." (James Robertson et al, "Complete Systems Analysis: The Workbook, the Textbook, the Answers", 2013)

"A connection between two tables based on a shared field." (Faithe Wempen, "Computing Fundamentals: Introduction to Computers", 2015)

"Any connection between two or more variables. In research, there are many types of relationships, from simple contingencies to established causal relationships." (K  N Krishnaswamy et al, "Management Research Methodology: Integration of Principles, Methods and Techniques", 2016)

"A defined connection between the rows of a table or the rows of two tables. A relationship is the internal representation of a referential constraint." (Sybase, "Open Server Server-Library/C Reference Manual", 2019)

🛢DBMS: Key (Definitions)

"A field used to identify a record, often used as the index field for a table." (Karen Paulsell et al, "Sybase SQL Server: Performance and Tuning Guide", 1996)

"A column or group of columns that uniquely identifies a row (PRIMARY KEY), defines the relationship between two tables (FOREIGN KEY), or is used to build an index." (Microsoft Corporation, "SQL Server 7.0 System Administration Training Kit", 1999)

"A data element (attribute or column) or the combination of several used to identify a member of a set, instance of an entity, or record in a table." (Sharon Allen & Evan Terry, "Beginning Relational Data Modeling" 2nd Ed., 2005)

"A data item or combination of data items used to identify or locate a record instance (or other similar data groupings)." (William H Inmon, "Building the Data Warehouse", 2005)

"A specialized field determining uniqueness, or application of referential integrity through use of primary and foreign keys." (Gavin Powell, "Beginning Database Design", 2006)

"Key is a data item that helps to identify individual occurrences of an entity type." (S. Sumathi & S. Esakkirajan, "Fundamentals of Relational Database Management Systems", 2007)

"A column or group of columns that uniquely identifies a row (primary key), defines the relationship between two tables (foreign key), or is used to build an index." (Jim Joseph et al, "Microsoft SQL Server 2008 Reporting Services Unleashed", 2009)

"A generic term for a set of one or more attributes (data items) that, taken collectively, enables one to identify uniquely an entity or a record in a SQL table; a superkey." (Toby J Teorey, ", Database Modeling and Design" 4th Ed., 2010)

"A data item or combination of data items designated to uniquely identify a particular entity instance or table row." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"An entity identifier based on the concept of functional dependence; may be classified as follows: Superkey - an attribute (or combination of attributes) that uniquely identifies each entity in a table. Candidate key - a minimal superkey, that is, one that does not contain a subset of attributes that is itself a superkey. Primary key (PK) - a candidate key selected as a unique entity identifier." (Carlos Coronel et al, "Database Systems: Design, Implementation, and Management" 9th Ed., 2011)

"A column or group of columns that uniquely identifies a row (primary key), defines the relationship between two tables (foreign key), or is used to build an index." (Microsoft, "SQL Server 2012 Glossary", 2012)

"The attributes that identify entity occurrences and define relationships between entities." (Craig S Mullins, "Database Administration", 2012)

"An identifying attribute of data" (Daniel Linstedt & W H Inmon, "Data Architecture: A Primer for the Data Scientist", 2014)

"In a relational database, a set of one or more fields that uniquely identifies a record." (Rod Stephens, "Beginning Software Engineering", 2015)

"In key-value databases, a key is a reference to a value. In relational databases, a key is also a way to reference a row in a table. Primary keys refer to the way of uniquely identifying a row. Foreign keys refer to keys stored in one table that are used to reference rows in other tables." (Dan Sullivan, "NoSQL for Mere Mortals®", 2015)

"One or more fields of a database record that uniquely identifies it among all other records in the table." (Nell Dale & John Lewis, "Computer Science Illuminated" 6th Ed., 2015)

"Sequence of bits that are used as instructions that govern the acts of cryptographic functions within an algorithm." (Adam Gordon, "Official (ISC)2 Guide to the CISSP CBK" 4th Ed., 2015)

"A column or an ordered collection of columns that is identified in the description of an index, unique constraint, or referential constraint. An index key can also be an expression, an ordered collection of expressions, or an ordered collection of columns and expressions." (Sybase, "Open Server Server-Library/C Reference Manual", 2019)

"A subset of row data that uniquely identifies a row. Key data uniquely describes the current row in an open cursor." (Sybase, "Open Server Server-Library/C Reference Manual", 2019)

🛢DBMS: Data Source (Definitions)

"The source of data for an object such as a cube or a dimension. Also, the specification of the information necessary to access source data. Sometimes refers to a DataSource object." (Microsoft Corporation, "SQL Server 7.0 System Administration Training Kit", 1999)

"A repository for storing data. An ODBC/JDBC term." (Peter Gulutzan & Trudy Pelzer, "SQL Performance Tuning", 2002)

"A file that contains the connection string that Analysis Services uses to connect to the database that hosts the data as well as any necessary authentication credentials." (Reed Jacobsen & Stacia Misner, "Microsoft SQL Server 2005 Analysis Services Step by Step", 2006)

"A system or application that generates data for use by another system or by an end user. The data source may also be the system of origin for the data." (Evan Levy & Jill Dyché, "Customer Data Integration", 2006)

"An information store that can be connected to by various SQL Server technologies such as SQL Server Reporting Services for data retrieval." (Marilyn Miller-White et al, "MCITP Administrator: Microsoft® SQL Server™ 2005 Optimization and Maintenance 70-444", 2007)

"An entity or group of entities from which data can be collected. The entities may be people, objects, or processes." (Jens Mende, "Data Flow Diagram Use to Plan Empirical Research Projects", 2009)

"An object containing information about the location of data. The data source leverages a connection string." (Jim Joseph et al, "Microsoft® SQL Server™ 2008 Reporting Services Unleashed", 2009)

"A repository of data to which a federated server can connect and then retrieve data by using wrappers. A data source can contain relational databases, XML files, Excel spreadsheets, table-structured files, or other objects. In a federated system, data sources seem to be a single collective database." (Sybase, "Open Server Server-Library/C Reference Manual", 2019)

🛢DBMS: Relational Model (Definitions)

"A method of organizing data into two-dimensional tables made up of rows and columns. The model is based on the mathematical theory of relations, a part of set theory." (Microsoft Corporation, "SQL Server 7.0 System Administration Training Kit", 1999)

"A model that provides a two-dimensional structure to data. The relational database model more or less throws out the window the concept and restriction of a hierarchical structure, but does not completely abandon data hierarchies. Any table can be accessed directly with having to access all parent objects. Precise data values (such as primary keys) are required to facilitate skirting the hierarchy (to find individual records) in specific tables." (Gavin Powell, "Beginning Database Design", 2006)

"A paradigm for describing the structure of a database in which entities are represented as tables, and relationships between the entities are represented by matching data." (Jan L Harrington, "Relational Database Design and Implementation" 3rd Ed., 2009)

"The relational model, based on mathematical set theory, represents data as independent relations. Each relation (table) is conceptually represented as a matrix of intersecting rows and columns. The relations are related to each other through the sharing of common entity characteristics (values in columns)." (Carlos Coronel et al, "Database Systems: Design, Implementation, and Management" 9th Ed., 2011)

"A database model based on first-order predicate logic [...]" (Craig S Mullins, "Database Administration: The Complete Guide to DBA Practices and Procedures", 2012)

"A form of data where data is normalized" (Daniel Linstedt & W H Inmon, "Data Architecture: A Primer for the Data Scientist", 2014)

"A type of model that aims to identify relationships of interest and quantify the strength of relationship between individuals or entities. Common examples include market basket analysis and social network analysis." (Evan Stubbs, "Big Data, Big Innovation", 2014)

"Data represented as a set of related tables or relations." (Jeffrey A Hoffer et al, "Modern Systems Analysis and Design" 7th Ed., 2014)

"A database model in which data and the relationships among them are organized into tables" (Nell Dale & John Lewis, "Computer Science Illuminated" 6th Ed., 2015)

"Relational modeling is a popular data modeling technique to reduce the duplication of data and ensure the referential integrity of the data." (Piethein Strengholt, "Data Management at Scale", 2020)

"(1) A data model whose pattern or organization is based on a set of relations, each of which consists of an unordered set of tuples. (2) A data model that provides for the expression of relationships among data elements as formal mathematical relations." (IEEE 610.5-1990)

OOP: Attribute (Definitions)

"Additional characteristics or information defined for an entity." (Owen Williams, "MCSE TestPrep: SQL Server 6.5 Design and Implementation", 1998)

"A named characteristic or property of a class." (Craig Larman, "Applying UML and Patterns", 2004)

"A characteristic, quality, or property of an entity class. For example, the properties 'First Name' and 'Last Name' are attributes of entity class 'Person'." (Danette McGilvray, "Executing Data Quality Projects", 2008)

"Another name for a field, used by convention in many object-oriented programming languages. Scala follows Java’s convention of preferring the term field over attribute." (Dean Wampler & Alex Payne, "Programming Scala", 2009)

"1. (UML diagram) A descriptor of a kind of information captured about an object class. 2. (Relational theory) The definition of a descriptor of a relation." (David C Hay, "Data Model Patterns: A Metadata Map", 2010)

"A fact type element (specifically a characteristic assignment) that is a descriptor of an entity class." (David C Hay, "Data Model Patterns: A Metadata Map", 2010)

"A characteristic of an object." (Requirements Engineering Qualifications Board, "Standard glossary of terms used in Requirements Engineering", 2011)

"An inherent characteristic, an accidental quality, an object closely associated with or belonging to a specific person, place, or office; a word ascribing a quality." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

OOP: Generalization (Definitions)

"The activity of identifying commonality among concepts and defining a superclass (general concept) and subclass (specialized concept) relationships. It is a way to construct taxonomic classifications among concepts which are then illustrated in class hierarchies." (Craig Larman, "Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process", 1997)

"The activity of identifying commonality among concepts and defining a superclass (general concept) and subclass (specialized concept) relationships. It is a way to construct taxonomic classifications among concepts, which are then illustrated in class hierarchies. Conceptual subclasses conform to conceptual superclasses in terms of intension and extension." (Craig Larman, "Applying UML and Patterns", 2004)

"The process of forming a more comprehensive or less restrictive class (a superclass) from one or more entities (or classes, in Unified Modeling Language [UML])." (Sharon Allen & Evan Terry, "Beginning Relational Data Modeling 2nd Ed.", 2005)

"In extended ER model (EER model), generalization is a structure in which one object generally describes more specialized objects." (S. Sumathi & S. Esakkirajan, "Fundamentals of Relational Database Management Systems", 2007)

"A special type of abstraction relationship that specifies that several types of entities with certain common attributes can be generalized (or abstractly defined) with a higher-level entity type, a supertype entity; an 'is-a' type relationship. For example, employee is a generalization of engineer, manager, and administrative assistant, based on the common attribute job-title. A tool often used to make view integration possible." (Toby J Teorey, ", Database Modeling and Design" 4th Ed., 2010)

"In a specialization hierarchy, the grouping together of common attributes into a supertype entity. See specialization hierarchy." (Carlos Coronel et al, "Database Systems: Design, Implementation, and Management 9th Ed", 2011)

"The process of evaluating multiple relationships between entities in a set into fewer relationships. Usually necessary after other generalization activities have taken place, which carry the relationships of the specialized entities into the generalized entities. For example, two 1:M relationships between two entities, each having a different parent, can be generalized into a M:N relationship." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"The process of recognizing commonalities, and combining similar types of entities or objects into a less specialized type based on common attributes and behaviors, creating a supertype for two or more specialized subtypes. Contrast with specialization." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"The abstraction, reduction, and simplification of features and feature classes for deriving a simpler model of reality or decreasing stored." (GRC Data Intelligence)

OOP: Object (Definitions)

"The type all other types derive from." (Jesse Liberty, "Programming C# 2nd Ed.", 2002)

"A set of variables and associated methods. An object can be sent messages to cause one of its methods to be executed." (Stephen G Kochan, "Programming in Objective-C", 2003)

"A specific instance of a class." (Marcus Green & Bill Brogden, "Java 2™ Programmer Exam Cram™ 2 (Exam CX-310-035)", 2003)

"In the UML, an instance of a class that encapsulates state and behavior. More informally, an example of a thing." (Craig Larman, "Applying UML and Patterns", 2004)

"An instance of a class, a thing, an entity, or a concept that is represented in contiguous memory in a computer. See instance, class." (Michael Fitzgerald, "Learning Ruby", 2007)

"A unique instance of a data structure defined according to the template provided by its class. Each object has its own values for the variables belonging to its class, and can respond to the methods defined by its class." (Craig F Smith & H Peter Alesso, "Thinking on the Web: Berners-Lee, Gödel and Turing", 2008)

"A cohesive unit with a particular state, possible state transitions, and behaviors. In Scala, the keyword object is used to declare a singleton explicitly, using the same syntax as class declarations, except for the lack of constructor parameters and auxiliary parameters (because objects are instantiated by the Scala runtime, not by user code). To avoid confusion with objects, we use the term instance to refer to instances of classes and objects generically." (Dean Wampler & Alex Payne, "Programming Scala", 2009)

"A cohesive unit with a particular state, possible state transitions, and behaviors. In Java, an object is an instance of a class." (Dean Wampler, "Functional Programming for Java Developers", 2011)

"A structure consisting of data and methods together with their interactions. An object is not just data, but the encapsulation of its state (data) and behavior (methods)." (Craig S Mullins, "Database Administration", 2012)

"An instance of a class. Something that 'knows' what user-defined type (class) it is, and what it can do because of what class it is. Your program can request an object to do things, but the object gets to decide whether it wants to do them or not. Some objects are more accommodating than others." (Jon Orwant et al, "Programming Perl" 4th Ed., 2012)

"A passive entity that contains or receives information. Access to an object potentially implies access to the information that it contains. Examples of objects include records, pages, memory segments, files, directories, directory trees, and programs." (Shon Harris & Fernando Maymi, "CISSP All-in-One Exam Guide, 8th Ed", 2018)

"In object-oriented design or programming, an abstraction that consists of data and operations associated with that data." (Sybase, "Open Server Server-Library/C Reference Manual", 2019)

"In an object-oriented programming context, an object is an instance of a class or type." (Alex Thomas, "Natural Language Processing with Spark NLP", 2020)

"The fundamental structural unit of an object-oriented programming language, encapsulating a set of data and behavior that operates on that data." (Daniel Leuck et al, "Learning Java, 5th Ed.", 2020)

"An instance of a class." (Rod Stephens, "Beginning Software Engineering", 2015)

"An entity or thing that is relevant in the context of a problem" (Nell Dale & John Lewis, "Computer Science Illuminated, 6th Ed.", 2015)

OOP: Instance (Definitions)

"A concrete representation of a class. Instances are objects that are typically created by sending an alloc or new message to a class object." (Stephen G Kochan, "Programming in Objective-C", 2003)

"An object of a particular class is called an instance of that class." (Marcus Green & Bill Brogden, "Java 2 Programmer Exam Cram 2 (Exam CX-310-035)", 2003)

"An individual member of a class. In the UML, called an object." (Craig Larman, "Applying UML and Patterns", 2004)

"A concrete representation of a class. Instances are objects that are typically created by sending an alloc or new message to a class object." (Stephen G Kochan, "Programming in Objective-C" 4th Ed., 2011)

"A specific object that is of a class type." (Rod Stephens, "Start Here! Fundamentals of Microsoft .NET Programming", 2011)

"An instance of a class is an object of the class's type. Different instances of the same class have the same properties, methods, and events but they may have different property values." (Rod Stephens, "Stephens' Visual Basic Programming 24-Hour Trainer", 2011)

"Another term for an object created by invoking a class constructor or a value of a primitive type." (Dean Wampler, "Functional Programming for Java Developers", 2011)

"(1) An occurrence of an entity. (2) The implementation of a database server (e.g., an Oracle instance)." (Craig S Mullins, "Database Administration: The Complete Guide to DBA Practices and Procedures 2nd Ed", 2012)

"In a map pattern one invocation of an elemental function on one element of the map." (Michael McCool et al, "Structured Parallel Programming", 2012)

"Short for 'an instance of a class', meaning an object of that class." (Jon Orwant et al, "Programming Perl" 4th Ed., 2012)

"One occurrence of something that has many occurrences, such as entities or objects." (James Robertson et al, "Complete Systems Analysis: The Workbook, the Textbook, the Answers", 2013)

"An entity to which a set of operations can be applied and that has a state that stores the effects of the operations." (Sybase, "Open Server Server-Library/C Reference Manual", 2019)

"An occurrence of something, usually an object. When a class is instantiated to produce an object, we say the object is an instance of the class." (Daniel Leuck et al, "Learning Java, 5th Ed.", 2020)