Database Terms Edit

# Edit

zero-to-zero cardinality - LINK - This is a 0:0 optional relationship basically stating that a person can occupy one parking space, that I don't need a person to have a space and I don't need a space to have a person. Although the concept is fairly simple, a database can't express it directly. You would need to nominate one entity to become the dominant table and use triggers or programs to limit the number of related records in the other table. [1]
0:M (Mandatory on the many side)
zero-to-many cardinality - Characteristic - This is a 0:M relationship that is mandatory on the many side. It indicates that a person must have at least one name, but possibly many names, and that a name might be assigned to a person (might not) but at most to one person. In a database you would have the the name table with a nullable foreign key to the person table and triggers or programs to force a person to have at least one name. [2]
0:M (Optional on both sides)
zero-to-many cardinality - Possession - This is a 0:M (zero to many) optional relationship indicating that a person might have no phone, one phone or lots of phones, and that a phone might be un-owned, but can only be owned by a maximum of one person. This is implemented in a database as a nullable foreign key column in the phone table that references the person table. [3]
one-to-zero cardinality - SubType - This is a 1:0 relationship; optional only on one side. This would indicate that a person might be a programmer, but a programmer must be a person. It is assumed that the mandatory side of the relationship is the dominant. Again, triggers or programs must be used to control the database. [4]
one-to-one cardinality - Physical Segment - This is a 1:1 mandatory relationship and demonstrates a segmentation denormalization. A person must have one and only one DNA pattern and that pattern must apply to one and only one person. This is difficult to implement in a database, since declarative referential integrity will get caught in a "Chicken and the Egg" situation. Basically, this is a single entity. [5]
1:M (mandatory on both sides)
one-to-many cardinality - Paradox - This is a 1:M relationship mandatory on both sides. As with the physical segment situation, the "Chicken and the Egg" is involved since you have to have a person to have citizenship, but citizenship to have a person. [6]
1:M (mandatory on the 1 side)
one-to-many cardinality - Child - This is a 1:M mandatory relationship, the most common one seen in databases. A person might be a member or might not, but could be found multiple times (if the member entity represents membership in multiple clubs, for instance). A member must be a person, no questions asked. The foreign key in the member table would be mandatory, or not-null. [7]
1NF First Normal Form
Eliminate repeating groups - Make a separate table for each set of related attributes, and give each table a primary key. - see Normalization [8]
2NF Second Normal Form
Eliminate redundant data - If an attribute depends on only part of a multi-valued key, remove it to a separate table. - see Normalization [9]
3NF Third Normal Form
Eliminate columns not dependent on key - If attributes do not contribute to a description of the key, remove them to a separate table. - see Normalization [10]
4NF Fourth Normal Form
Isolate independent multiple relationships - see Normalization [11]
5NF Fifth Normal Form
Isolate independent multiple relationships - No table may contain two or more 1:M or M:M relationships that are not directly related. - see Normalization [12]

A-B-C Edit

Alternate Key
Isolate Semantically Related Multiple Relationships - There may be practical constrains on information that justify separating logically related M:M relationships. [13] [14] [15]
Analysis and Design
The goal of Systems Analysis is to capture an accurate representation of business processes and user's perceptions of them. Logical design of the information system including identification of databases (tables, columns, keys, indexes) that will store required data and applications (forms, reports, menus) that will operate on the database. [16] [17]
Artificial Key
An artificial key is one that has no meaning to the business or organization. Artificial keys are used when 1) no attribute has all the primary key properties, or 2) the primary key is large and complex, or 3) all candidate keys are subject to updates
Associative Table
An associative table is not allowed without one or more Main Tables.
Each column of a table represents an attribute. Attributes are data items that describe an entity. An attribute instance is a single value of an attribute for an instance of an entity.
BCNF Boyce-Codd Normal Form
If there are non-trivial dependencies between candidate key attributes, separate them out into distinct tables.Falls between 3NF and 4NF - see Normalization
Candidate Key
A candidate key is a minimal set of columns necessary to identify a row, this is also called a minimal superkey [18] [19]
numeric realtionship between entities, for example one-to-one
Compound Key
a compound key (also called a composite key or concatenated key) is a key that consists of 2 or more attributes [20]
Conceptual Data Model
High level business model showing entities and relationships without keys, cardinality, or attributes.

D-E-F Edit

Data Integrity Rules [21]
Data Objects and Relationships
Identifying Data Objects and Relationships during requirements analysis [22]
DBM Database Management Systems [23] [24]
Represented by a main table
Entity-Relationship [25]
E-R Diagram
see Foreign Key
Flexible Database Model [26]
Foreign Key
- A foreign key in one table refers to the primary key (PK) of another table. [27]
- A foreign key is an attribute that completes a relationship by identifying the parent entity. Foreign keys provide a method for maintaining integrity in the data (called referential integrity) and for navigating between different instances of an entity. Every relationship in the model must be supported by a foreign key. [28]

G-H-I Edit

Process of categorizing entities by their similarities and differences
Generalization Hierarchy
A structured grouping of entities that share common attributes. It is a powerful and widely used method for representing common characteristics among entities while preserving their differences. It is the relationship between an entity and one or more refined versions. The entity being refined is called the supertype and each refined version is called the subtype. [29]
In an overlapping hierarchy an entity instance can be part of multiple subtypes.
In a disjoint hierarchy, an entity instance can be in only one subtype.
Subtypes may be the parent entity in a relationship but not the child. If this were allowed, the subtype would inherit two primary keys.
Other database design glossarys [30]

J-K-L Edit

A value used to lookup a record, may be unique or non-unique
Logical Data Model
An extension of the Conceptual Data Model. Normalized entity relationship model with main tables, associative tables, keys, cardinality, business contraints, and main attributes.

M-N-O Edit

many-to-many cardinality - Association - This is a M:M (many to many) optional relationship. Conceptually, it means that a person might or might not work for an employer, but could certainly moonlight for multiple companies. An employer might have no employees, but could have any number of them. Again, not hard to visualize, but hard to implement. Most solutions of this situation involve creating a third "Associative Entity" to resolve the M:M into two 0:M relationships. This might be an entity called employee because it does link the person to the employer the person works for. [31]
Main Table
an entity - records can exist in a main table without the presence of other tables, unless a foreign key is required.
Name conventions
Table and attribute names are all lower case. Words are separated by hyphens, not spaces or underscores. Associative table names are formed by linking table names with hyphens, for example animal-person.
Natural Key
a key that has a real world value, like social security number
Rules of data normalization - see references [32][33][34]
Unknown value [35]
ORM Object Role Modeling [36] [37]

P-Q-R Edit

Physical Data Model
De-normalized version of the Logical Data Model with all required attributes and attribute domains needed to implement in the target database engine. May or may not include all the entities defined in the Logical Data Model.
see Primary Key
Primary Key
A value that can be used to identify a unique row in a table [38]
The primary key is an attribute or a set of attributes that uniquely identify a specific instance of an entity. Every entity in the data model must have a primary key whose values uniquely identify instances of the entity.[39]
Primary Key Migration
Dependent entities, entities that depend on the existence of another entity for their identification, inherit the entire primary key from the parent entity. Every entity within a generalization hierarchy inherits the primary key of the root generic entity. [40]
One row in a table and associated rows in other tables.
Recursive relationship
A recursive relationship is an entity associated with itself. Example - An employee may manage many employees and each employee is managed by one employee.
Referential Integrity
Referential integrity means that if a row in a table has a pointer to a row in another table, the row in the table that is pointed at, must be sound (exist). Said another way, you should not remove a row which contains information that other row(s) depend on. [41]
Relational Data Manipulation [42]
Union, Difference, Intersection, Product, Projection, Selection, Join, Division
Relationships and Keys [43]
see diagram illustration

S-T-U Edit

a superkey is a set of columns within a table whose values can be used to uniquely identify a row [44]
In a relational database, a tuple is one record (one row in a table) [45]
Unique Key
a unique key refers to the attribute which is unique for that column of the table - a unique value is often an integer provided by the database but can be a natural key such as SSN. [46]

V-W-X-Y-Z Edit

See also Edit

Internal links Edit

External links Edit

Categories Edit