Karteikarten
Database Management
Karten in diesem Stapel (20)
- 1Identifiers (Primary Keys)Underlined
in Bold
Use the initials “PK” before or after the primary key field name - 2DomainsAttributes/fields have domain
Domain is a field’s set of possible values
Applies to both numeric and char fields - 3Composite Primary KeysPrimary keys ideally composed of only single attribute
Possible to use a composite key (several fields make up the PK)
The most efficient PKs are short and numeric - 4EntitiesCorresponds to a table
Represented by rectangle containing entity’s name
Entity name, a noun, is usually written in capital letters in the singular
e.g. STUDENT, INSTRUCTOR, ENROLLMENT - 5ERDs depict database’s main components:Entities/Tables
Attributes/Fields
Relationships
Narrative
Cardinality/Numerical - 6Attributes/FieldsBeneficial to include them on an ERD
Saves time looking them up in the data dictionary
Crow’s foot model preferred (see next slide)
Indicate the PK & any FKs - 7RelationshipsAssociation between entities
Relationships between entities always operate in both directions
The numeric relationship (cardinality) can be classified as
1:1
1:M
M:1
M:N (in class we use the term M:M) - 8Derived AttributesAttribute whose value may be calculated (derived) from other attributes
Need not be physically stored within database
Can be derived by using an algorithm
Called a “calculated” field in Access - 9CardinalityCardinality = the numeric relationship
Derived from the business rules
An examination of the keys and/or the data will tell you what the cardinality actually is if you are unfamiliar with the DB - 10Parent – Child RelationshipIt’s really a 1:M
The “1” table contains the Parent records
The “M” table contains the Children records - 11Relationship StrengthWeak (non-identifying) relationships
Strong (Identifying) Relationships - 12Weak (non-identifying) relationshipsExists if PK of related entity does not contain PK component of parent entity (1:M)
i.e. an FK exists in the child but it is not part of its PK - 13Strong (Identifying) RelationshipsExists when PK of related entity contains PK component of parent entity
i.e. an FK exists in the child and it is part of its PK - 14Recursive RelationshipsA table can be related to itself
- 15Associative EntitiesAlso known as bridge or composite entities
Composed of primary keys of each of the entities to be connected
May also contain additional attributes that play no role in connective process
Used to resolve M: M relationships - 16Developing an ERDDatabase design is iterative rather than linear or sequential process
Iterative process
Based on repetition of processes and procedures
Often refined
Building an ERD usually involves the following activities:
Analysis phase
Gather the fields
Find themes – they become tables
Determine PKs
Determine Relationships
Text
Cardinality
Determine FKs
Resolve M:Ms - 17Database Design GoalsData Availability
Data Integrity
Ease of Use
Security
Growth
Sharable
Performance/Speed
Ability for Applications to integrate the DB into their systems - 181NF An logical entity (or physical table) is in first normal form if:It complies with the rules for a valid table (see slide Ch 4.1 (order of rows unimportant, etc.)
There are no repeating groups - 192NF An logical entity (or physical table) is in second normal form ifit is already in first normal form
and if the values of all non-primary key attributes are dependent on the full primary key
Applies only to tables which have a compound key - 203NF An logical entity (or physical table) is in third normal form ifit is already in second normal form
and if the values of all non-primary key attributes are not dependent on other non-primary key attributes
Informationen
- Beschreibung
- Karteikarten am Database Management, erstellt von Andy Oung am 07/04/2015.
- Erstellt von
- Andy Oung
- Aufrufe
- 3
- Bewertung